All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.