Jon Loeliger wrote: > The other day, I was talking to some other folks else-list > about git's approach to merges and mentioned that there was > some structure in place to handle different merge strategies. > > One person observed that Perforce had a really good > approach to merging and conflict resolution that allowed > user interaction during the process specifically to > help select the individual files and hunks that contributed > to the final result. I confess that I have never used > Perforce, so this is all hear-say and interpretation. :-) > > However, it does seem like an approach that we could > easily add to git -- not as the default of course. > (Just think how dead we'd all be if Linus had to manually > interact with every merge he performed at the tip of the > Linux Pyramid. :-) > > 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. And select which files are which (after renaming, copying, etc.) > Any thoughts down this line? Good idea? Bad idea? Wouldn't it be better to fallback to graphical/user guided merger only on _failed_ merge? Merge helpers like xxdiff, Meld or KDiff3 http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist There was proposal of git script which run xxdiff with correct extracted files, if I remeber correctly postponed waiting for more generic version. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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