Antoine Pelisse <> writes:

> 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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to