From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Julian Phillips" <julian@quantumfyre.co.uk>,
"Uwe Kleine-König" <ukleinek@informatik.uni-freiburg.de>,
git@vger.kernel.org
Subject: Re: name-rev does not show the shortest path
Date: Sun, 26 Aug 2007 17:38:22 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.64.0708261733400.16728@wbgn129.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <20070826092323.GB30474@coredump.intra.peff.net>
Hi,
On Sun, 26 Aug 2007, Jeff King wrote:
> On Sat, Aug 25, 2007 at 05:04:33PM +0200, Johannes Schindelin wrote:
>
> > I briefly looked into this, and did not find out why it is behaving that
> > way. It _should_ pick the closer one with this code:
> >
> > } else if (name->merge_traversals > merge_traversals ||
> > (name->merge_traversals == merge_traversals &&
> > name->generation > generation)) {
> >
> > However, it did not even get to that code in my tests. I'll have to look
> > at that problem closer in a quiet moment (which I will not have for at
> > least another 24 hours).
>
> It does execute that code, just not for the rev in question. We hit the
> third part of that conditional and stop recursing on a different rev, so
> we only touch our "interesting" rev one time.
Yes, I guessed as much.
> That being said, I think this test is totally bogus. You're just looking
> at the generation and merge traversals from some tip. However, the tip
> _isn't_ the actual ref, but instead gets re-written as a string when we
> follow a merge. That string contains important generational information
> that is no longer taken into account, so you end up with things like
> "foo~999" with generation "3" is better than "bar~10" with generation
> "5".
But this did not happen here, right? Just the first part was different...
> Here is a patch (below) that tracks an absolute "distance to ref" and at
> least names the rev in question after v2.6.22-rc1. However, because it
> is now preferring "distance to ref" strictly over merge traversals, it
> seems to generate some obscenely long names:
>
> 0567a0c022d5b343370a343121f38fd89925de55 tags/v2.6.22-rc1~1^2^2^2~11^2~13^2~8^2~1^3~5
>
> So perhaps there is a more sane metric, but I'd have to think about it
> more.
The old code _should_ have worked; it is more likely that your different
metric just hides the bug. The old metric tried to favour less merge
traversals over more traversals, but at the same time, it favoured smaller
numbers over larger ones (but as you found out, only in the last
component).
I guess there is something else going on, such as the tag v2.6.22-rc1
being marked uninteresting because v2.6.22 and its ancestors being
traversed already.
Ciao,
Dscho
next prev parent reply other threads:[~2007-08-26 15:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-23 10:38 name-rev does not show the shortest path Uwe Kleine-König
2007-08-24 11:55 ` Julian Phillips
2007-08-24 12:52 ` Uwe Kleine-König
2007-08-24 15:21 ` Julian Phillips
2007-08-24 18:33 ` Junio C Hamano
2007-08-25 15:04 ` Johannes Schindelin
2007-08-26 9:23 ` Jeff King
2007-08-26 15:38 ` Johannes Schindelin [this message]
2007-08-27 9:24 ` Jeff King
2007-08-27 9:57 ` Johannes Schindelin
2007-08-27 11:18 ` Johannes Schindelin
2007-08-27 11:37 ` [PATCH] name-rev: Fix non-shortest description Johannes Schindelin
2007-08-27 19:27 ` Uwe Kleine-König
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
List information: http://vger.kernel.org/majordomo-info.html
* 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.0708261733400.16728@wbgn129.biozentrum.uni-wuerzburg.de \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=julian@quantumfyre.co.uk \
--cc=peff@peff.net \
--cc=ukleinek@informatik.uni-freiburg.de \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).