git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).