From: Tuomas Suutari <tuomas.suutari@gmail.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: git@vger.kernel.org, Sam Vilain <sam@vilain.net>,
Eric Wong <normalperson@yhbt.net>
Subject: Re: [PATCH 3/3] git-svn: Fix discarding of extra parents from svn:mergeinfo
Date: Mon, 22 Feb 2010 20:04:55 +0200 [thread overview]
Message-ID: <201002222004.55898.tuomas.suutari@gmail.com> (raw)
In-Reply-To: <201002221057.35088.trast@student.ethz.ch>
On Mon 2010-02-22 11:57:34 Thomas Rast wrote:
> On Monday 22 February 2010 08:57:22 Tuomas Suutari wrote:
> > Use merge-base rather than rev-list for detecting if a parent is an
> > ancestor of another, because rev-list gives incorrect results
> > sometimes.
>
[...]
>
> I think you swapped the test (or I got confused, which is entirely
> possible).
Ah, seems so. I was already writing a long reply explaining why rev-list
can't be used but only merge-base just to realize that, indeed, rev-list can
be used after all. The code just used to discard the wrong parent.
> Let I = $new_parents[$i] and J = $new_parents[$j]. The
> old one was
>
> test -z "$(git rev-list -1 I..J)"
>
> which reads "unless there are any commits on J which are not on I",
> i.e., it fails unless J is an ancestor of I.
>
> But the new one is
>
> "$(git merge-base I J)" == I.
>
> so suddenly I must be an ancestor of J.
>
> Is that what you were fixing?
Yes.
> Because I don't think the 'rev-list -1'
> test is any worse than the merge-base test.
You're right. I failed to see that I can get the same results by swapping $i
with $j in the undef($new_parents[$i]) statement.
My pitfall was that I considered only changing the "if ( !$revs )" part to
"if ( $revs )" with the rev-list approach. That wouldn't have worked,
because then the other test case, included in PATCH 2, would have failed.
(When there are two distinct branches merged to one.)
> If it's not, please tell
> us what you are fixing. Either way, please change the commit message
> appropriately.
Yes, the commit message was horrible. I was hoping that, by writing a test
case as a "description" about the problem, I would avoid writing so much
English... ;)
I will send another patch soon. Hopefully with better commit message.
--
Tuomas
next prev parent reply other threads:[~2010-02-22 18:05 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 [this message]
2010-02-22 18:12 ` [PATCH 3/3 v2] " Tuomas Suutari
2010-02-23 16:58 ` Thomas Rast
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=201002222004.55898.tuomas.suutari@gmail.com \
--to=tuomas.suutari@gmail.com \
--cc=git@vger.kernel.org \
--cc=normalperson@yhbt.net \
--cc=sam@vilain.net \
--cc=trast@student.ethz.ch \
/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.