git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: Proposal for new git Merge Strategy
Date: Wed, 23 Aug 2006 21:02:09 +0200	[thread overview]
Message-ID: <eci8nh$uk3$1@sea.gmane.org> (raw)
In-Reply-To: E1GFxeZ-0000Nw-ED@jdl.com

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

  reply	other threads:[~2006-08-23 19:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-23 18:40 Proposal for new git Merge Strategy Jon Loeliger
2006-08-23 19:02 ` Jakub Narebski [this message]
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='eci8nh$uk3$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.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).