All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Anders Melchiorsen" <mail@cup.kalibalik.dk>,
	git@vger.kernel.org, "Samuel Tardieu" <sam@rfc1149.net>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"SZEDER Gábor" <szeder@ira.uka.de>
Subject: Re: [PATCH] Fix for a merge where a branch has an F->D transition
Date: Wed, 13 May 2009 11:59:29 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302> (raw)
In-Reply-To: <81b0412b0905122338q774454cj65edfde3d73948e3@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1346 bytes --]

Hi,

On Wed, 13 May 2009, Alex Riesen wrote:

> 2009/5/13 Junio C Hamano <gitster@pobox.com>:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> >> Frankly, I'm not really sure. The solution came largely ... empirical
> >> way. IOW, I tried more or less random things which looked like they
> >> should fix the problem. So a review is very much appreciated. Please.
> >
> > I've always thought that D/F conflict logic in merge-recursive is placed
> > at the wrong processing phase.  IIRC, it enumerates potential D/F
> > conflicting paths before even attempting to process renames, and it is
> > easy to miss a path that was previously file going away as the result of a
> > clean merge (in which case it is ok to have a directory there as the
> > result of a merge for other paths).  This breakage could be a small
> > example of it.
> >
> > Regardless, I think your patch is a reasonable fix to go to the
> > maintenance track.  Thanks for looking into it.
> 
> I'm afraid the fix is not that simple: the "if" branch where the change
> is placed supposed to prevent updating files in the working tree
> which already have the same content as the merge's output.
> My change may force them to be updated regardless. I think...
> Johannes, you know this area the best, could you please have
> a look?

Sorry, no time at the moment...

Ciao,
Dscho

  reply	other threads:[~2009-05-13  9:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11  9:42 [PATCH] Add a reminder test case for a merge with F/D transition Alex Riesen
2009-05-11 19:25 ` [PATCH] Fix for a merge where a branch has an F->D transition Alex Riesen
2009-05-13  6:19   ` Junio C Hamano
2009-05-13  6:38     ` Alex Riesen
2009-05-13  9:59       ` Johannes Schindelin [this message]
2009-05-13 11:33         ` Alex Riesen
2009-05-20 10:34   ` Johannes Schindelin
2009-05-20 22:09     ` Alex Riesen

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=alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302 \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mail@cup.kalibalik.dk \
    --cc=raa.lkml@gmail.com \
    --cc=sam@rfc1149.net \
    --cc=szeder@ira.uka.de \
    --cc=torvalds@linux-foundation.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.