Antoine Pelisse <apeli...@gmail.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
