Jon Loeliger <jdl@xxxxxxx> writes:
> But for complex or critical merges, a "guided merge"
> strategy seems like it might be a useful tool. Basically,
> it would offer options to select Stage 1 or Stage 2
> revisions, or step in and offer hunks from Stage 1 and 2,
> revert to "ours" or "theirs", or "revert to 'ours' or 'theirs'
> for all remaining files". Things like that maybe.
>
> Any thoughts down this line? Good idea? Bad idea?
We had some discussion on this with Catalin in "Unresolved
issues #3" thread, regarding git-xxdiff (did I ever take it? I
liked it for what it does, but I was not sure about its
odd-man-out-ness) which was proposed by Martin Langhoff.
A merge that results in manual fixups conceptually take these
steps:
- revs involved in 3-way merge identified with git-merge-base;
- read-tree is given these three bases;
- git-merge-index gives three stages as individual temporary
files to git-merge-one-file for each path that cannot be
resolved at tree-level.
- git-merge-one-file calls "merge" (reminds me that I should
replace this with "diff3").
We should be able to make the part that call "merge/diff3" to
alternatively call xxdiff or its friends (kompare, emerge, pick
your favorites). Catalin even showed us a code snippet used in
StGIT for this in the thread.
Martin's proposed tool git-xxdiff is meant to be invoked after
all of the above still left conflict markers. As Catalin
pointed out, using "xxdiff -U" to work on a file with conflict
markers is less powerful than working on three stages directly,
but on the other hand it can be used as the last stage fixup,
independent from what git-merge does internally. In other
words, it is meant to help solving the same problem but in a
different part of the workflow.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html