Folks,
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.
Any thoughts down this line? Good idea? Bad idea?
Thanks,
jdl
PS -- Please keep mwm on the CC: list as he doesn't
directly subscribe to the git list, but would
like to participate in the thread. Thanks!
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