Re: Premerging topics

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2013, 22:19 UTC
Message-ID: <7v61z5geu1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALWbr2wiYkHMSihh-X-ToO-j4fty-P5OHicHa8ZUoqBkLS5mow@mail.gmail.com>

Antoine Pelisse <apelisse@gmail.com> writes:

Show 8 quoted lines

> Should we think about adding some commands for that ?
>
> On the very top of my head (there is certainly more than that):
> - Save such a change: By basically creating a ref to HEAD (HEAD being
> the commit, HEAD^ the fixed merge) with merge-fix/HEAD^^1-HEAD^^2
> - Apply the merge-fix: On top of a merge, find the most recent
> merge-fix for HEAD^1/HEAD^2 (according to what was discussed), and
> squash it.

Yeah, some nasties may live in the details, but these two operations are needed and probably sufficient as the end-user facing UI.

The "save" step, when done manually, needs to be a two-step process that saves M and then F separately, but somebody _might_ be able to come up with a clever idea to let the user jump directly to F without recording M. If such a triangle (A and B merges to F) can be recorded as merge-fix/A-B, that would certainly be less error prone and easier for the users to use. Having said that, in the presense of possible textual conflicts when creating M, I do not think of a way that is easily implementable mechanically to internally sift changes for M and F when replaying it while resolving a merge between X and Y to produce N and eventually F'.

The "apply" step should be a single step, and it should be easy to implement mechanically if M and F are recorded separately (but again, you may be able to re-synthesise M from A and B when you need to replay the evil merge).