All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@student.ethz.ch>
To: Tuomas Suutari <tuomas.suutari@gmail.com>
Cc: <git@vger.kernel.org>, Sam Vilain <sam@vilain.net>,
	Eric Wong <normalperson@yhbt.net>
Subject: Re: [PATCH 3/3 v2] git-svn: Fix discarding of extra parents from svn:mergeinfo
Date: Tue, 23 Feb 2010 17:58:04 +0100	[thread overview]
Message-ID: <201002231758.05297.trast@student.ethz.ch> (raw)
In-Reply-To: <1266862373-28365-1-git-send-email-tuomas.suutari@gmail.com>

On Monday 22 February 2010 19:12:53 Tuomas Suutari wrote:
> If parent J is an ancestor of parent I, then parent J should be
> discarded, not I.
> 
> Note that J is an ancestor of I if and only if rev-list I..J is emtpy,
> which is what we are testing here.
> 
> Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
> ---
> Thanks to Thomas Rast for pointing out that this can be made with a
> smaller change and there is no need swap rev-list to merge-base after
> all.
[...]
> -					undef($new_parents[$i]);
> +					undef($new_parents[$j]);

Just so this doesn't get lost...

I'm hesitating to give my "Ack", since I haven't looked into what the
surrounding code does.  I can't even see at a glance how the parent
reduction relates to the commit that introduced it, which was

  commit 7a955a5365d9ebd5e12c12ed926b2b51b61c02ee
  Author: Sam Vilain <sam@vilain.net>
  Date:   Sun Dec 20 05:26:26 2009 +1300

      git-svn: detect cherry-picks correctly.

      The old function was incorrect; in some instances it marks a cherry picked
      range as a merged branch (because of an incorrect assumption that
      'rev-list COMMIT --not RANGE' would work).  This is replaced with a
      function which should detect them correctly, memoized to limit the expense
      of dealing with branches with many cherry picks to one 'merge-base' call
      per merge, per branch which used cherry picking.

      Signed-off-by: Sam Vilain <sam@vilain.net>
      Acked-by: Eric Wong <normalperson@yhbt.net>


That being said, you have clearly addressed the points I raised in my
earlier mail.  The loop, taken by itself, now throws out elements of
the $new_parents list that are ancestors of another element which is a
sane thing to do if you're building a merge.

So with the catch that I only looked at the immediate neighbourhood in
the code:

  Acked-by: Thomas Rast <trast@student.ethz.ch>


-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  reply	other threads:[~2010-02-23 16:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-22  7:57 git-svn detects some merges incorrectly from svn:mergeinfo Tuomas Suutari
2010-02-22  7:57 ` [PATCH 1/3] t9151: Fix a few commits in the SVN dump Tuomas Suutari
2010-02-24 23:14   ` Sam Vilain
2010-02-22  7:57 ` [PATCH 2/3] t9151: Add two new svn:mergeinfo test cases Tuomas Suutari
2010-02-22  7:57 ` [PATCH 3/3] git-svn: Fix discarding of extra parents from svn:mergeinfo Tuomas Suutari
2010-02-22  9:57   ` Thomas Rast
2010-02-22 18:04     ` Tuomas Suutari
2010-02-22 18:12   ` [PATCH 3/3 v2] " Tuomas Suutari
2010-02-23 16:58     ` Thomas Rast [this message]
2010-02-26  9:50 ` git-svn detects some merges incorrectly " Eric Wong

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=201002231758.05297.trast@student.ethz.ch \
    --to=trast@student.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=sam@vilain.net \
    --cc=tuomas.suutari@gmail.com \
    /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.