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
next prev parent 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).