From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org, Junio C Hamano <junkio@cox.net>,
Tom Prince <tom.prince@ualberta.net>
Subject: Re: [PATCH] Keep rename/rename conflicts of intermediate merges while doing recursive merge
Date: Sat, 31 Mar 2007 09:07:56 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703310856070.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <20070331114938.GB4377@steel.home>
On Sat, 31 Mar 2007, Alex Riesen wrote:
>
> The result seem to be at least predictable. Still, doesn't it mean
> that once a rename/rename conflict is in it has to be resolved
> manually forever?
No. It means that that particular rename/rename conflict has to be
resolved *once*, since after that, the new merge will become the
merge-base for future merges.
Now, that doesn't mean that you may not end up having that same conflict
show up over and over again, because the new merge-base may (obviously)
end up being a situation where the rename/rename conflict will continue to
exist later on (because it conflicts with what the repo you pulled from
will continue to have), but that's really no different from any other
conflict..
The only way to resolve some conflicts in the long run is to either
- converge on some common case (ie normally by merging both ways
eventually, or just try to converge otherwise)
- remember the conflict resolution and re-doing it automatically (ie
"git rerere" for rename conflicts)
That's very fundamental, btw. I don't think there *is* any other way to do
automatic merges in the long run, it has nothing to do with this
particular issue, it's a generic property of automatic merging.
Junio - I think Alex' patch is better than what we have right now (which
is dying - whether with a SIGSEGV or a die() doesn't much matter), so it
should be applied. It probably isn't perfect, and I bet we can tweak the
resolution to something much better - Dscho seems to have ideas in that
areas. But:
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
in the meantime.
One thing we could/probably should do is to perhaps just add a flag about
"intermediate merges had complex issues", and refuse to commit the result
even if it looked "clean" in the end. It's better to make people perhaps
have to do an "unnecessary" extra git-commit, than to silently commit
something that might have been mis-merged. Just ask people to "please
verify the end result" kind of thing..
Linus
next prev parent reply other threads:[~2007-03-31 16:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-29 7:50 SEGV in git-merge recursive: Tom Prince
2007-03-29 8:18 ` Alex Riesen
2007-03-29 8:32 ` Tom Prince
2007-03-29 11:29 ` Alex Riesen
2007-03-29 12:58 ` Tom Prince
2007-03-29 13:34 ` Alex Riesen
2007-03-29 14:12 ` Tom Prince
2007-03-29 14:44 ` Alex Riesen
2007-03-29 14:45 ` Alex Riesen
2007-03-29 15:04 ` Tom Prince
2007-03-29 15:04 ` Alex Riesen
2007-03-29 18:32 ` Alex Riesen
2007-03-29 18:55 ` Alex Riesen
2007-03-29 23:01 ` [PATCH] An attempt to resolve a rename/rename conflict in recursive merge Alex Riesen
2007-03-29 23:13 ` Alex Riesen
2007-03-29 19:34 ` SEGV in git-merge recursive: Linus Torvalds
2007-03-29 19:40 ` Linus Torvalds
2007-03-29 20:44 ` Alex Riesen
2007-03-30 21:00 ` Johannes Schindelin
2007-03-31 0:35 ` Linus Torvalds
2007-03-31 1:03 ` Linus Torvalds
2007-03-31 10:49 ` Alex Riesen
2007-03-31 11:49 ` [PATCH] Keep rename/rename conflicts of intermediate merges while doing recursive merge Alex Riesen
2007-03-31 12:06 ` Jakub Narebski
2007-03-31 12:50 ` Johannes Schindelin
2007-03-31 12:53 ` Johannes Schindelin
2007-03-31 16:07 ` Linus Torvalds [this message]
2007-03-31 17:34 ` Alex Riesen
2007-03-31 20:03 ` Junio C Hamano
2007-03-31 11:22 ` SEGV in git-merge recursive: Johannes Schindelin
2007-03-29 19:55 ` Tom Prince
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=Pine.LNX.4.64.0703310856070.6730@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=raa.lkml@gmail.com \
--cc=tom.prince@ualberta.net \
/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).