[petsc-dev] private branch of petsc-dev (fwd)

[Jed Brown]

On Sat, Feb 9, 2013 at 6:56 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> So, this resolution is applied to jed/test and also saved [I'm guessing
> the detached HEAD is this stashed resolution?)


Whoops, I copied the log message from a different context rather than
setting up a full example. There's no detached HEAD in the setup I
explained. (Junio's post suggests doing the throw-away merge in detached
HEAD only because it saves the step of deleting the throw-away branch.)

Implementation-wise, the resolution is stored in .git/rr-cache. If
interacting with other people on jed/feature2, I might publish my
"throw-away" merge so that other people could access the merged state in
their own throw-away merges. (This is the purpose of 'pu' in kerne/git
workflow.)


> to be applied again later to master when jed/feature2 is finally merged
> with the upstream.  Meanwhile you work on jed/feature2 without this
> resolution applied, so you don't actually see the code as it will end up.


I'm assuming here that the conflict is incidental, not core to the way
feature2 functions. Common examples are adjacent lines in headers or
registration routines. If the merge is not helpful for the implementation
and proper functioning of feature2, they shouldn't exist in the
jed/feature2 branch.


>  Wouldn't that be confusing?  I imagine this workflow works and "preserves
> the ... testing" because the testing is done on jed/test, which contains
> the resolutions of all of the conflicts with the upstream.  I feel like I
> would find it disorienting working on one branch, testing in another, then
> fixing whatever problems in the first, testing again in the second, and so
> on. What am I missing?


You test in the feature branch, the purpose of which is to tell a complete,
but uncluttered story of the implementation of that feature. The purpose of
the throw-away branch is (a) to confirm that we don't have real conflicts
that will be messy to sort out later and (b) to run with the latest
experimental everything, e.g., if an application is prepared to leverage
many new features at once and we don't have a suitable test.

This blog post has a good discussion of the purpose of branches and merges.

http://gitster.livejournal.com/42247.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130209/b644c5d1/attachment.html>