git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl@jdl.com>
To: git@vger.kernel.org
Cc: mwm@mired.org
Subject: Proposal for new git Merge Strategy
Date: Wed, 23 Aug 2006 13:40:39 -0500	[thread overview]
Message-ID: <E1GFxeZ-0000Nw-ED@jdl.com> (raw)

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!

             reply	other threads:[~2006-08-23 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-23 18:40 Jon Loeliger [this message]
2006-08-23 19:02 ` Proposal for new git Merge Strategy Jakub Narebski
2006-08-23 20:00 ` Junio C Hamano
2006-08-23 23:05   ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1GFxeZ-0000Nw-ED@jdl.com \
    --to=jdl@jdl.com \
    --cc=git@vger.kernel.org \
    --cc=mwm@mired.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).