Proposal for new git Merge Strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]