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: "Anders Melchiorsen" <mail@cup.kalibalik.dk>,
	git@vger.kernel.org, "Samuel Tardieu" <sam@rfc1149.net>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"SZEDER Gábor" <szeder@ira.uka.de>
Subject: Re: [PATCH] Fix for a merge where a branch has an F->D transition
Date: Wed, 20 May 2009 12:34:52 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0905201228040.16461@intel-tinevez-2-302> (raw)
In-Reply-To: <20090511192536.GA1485@blimp.localdomain>

Hi,

On Mon, 11 May 2009, Alex Riesen wrote:

> Some path names which transitioned from file to a directory were not
> updated in the final part of the merge (loop around unmerged entries in
> merge_trees), because the branch in process_renames which filtered out
> updates for the files with the same content ("merged same as existing")
> has left the rename entry in processed state. In this case, the
> processing cannot be finished at the process_renames phase (because
> the old file still blocks creation of directory where new files should
> appear), and must be postponed until the update_entry phase.

I know that as a German, I am supposed to like long sentences and crowded 
paragraphs.  Maybe I am not that German after all.

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

This does not give me the cozy feeling I need to review a patch.  After 
all, I do not want to do all the work that should be done by the patch 
author, but I just want to put in my knowledge to verify that the patch 
is correct.

But as you asked me explicitely...

> diff --git a/merge-recursive.c b/merge-recursive.c
> index a3721ef..3c5420b 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,
>  
>  				if (mfi.clean &&
>  				    sha_eq(mfi.sha, ren1->pair->two->sha1) &&
> -				    mfi.mode == ren1->pair->two->mode)
> +				    mfi.mode == ren1->pair->two->mode) {
>  					/*
>  					 * This messaged is part of
>  					 * t6022 test. If you change
>  					 * it update the test too.
>  					 */
>  					output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
> -				else {
> +					ren1->dst_entry->processed = 0;
> +				} else {

So basically, you say that a dst_entry has not been processed, when it 
_has_ been?  That cannot be correct...

Ciao,
Dscho

  parent reply	other threads:[~2009-05-20 10:35 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
2009-05-13 11:33         ` Alex Riesen
2009-05-20 10:34   ` Johannes Schindelin [this message]
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.0905201228040.16461@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.