<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 6:56 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So, this resolution is applied to jed/test and also saved [I'm guessing the detached HEAD is this stashed resolution?)</blockquote>

<div><br></div><div>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.)</div>

<div><br></div><div>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 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.</blockquote>
<div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  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?</blockquote>

</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>This blog post has a good discussion of the purpose of branches and merges.</div><br><a href="http://gitster.livejournal.com/42247.html">http://gitster.livejournal.com/42247.html</a><br>
</div></div>