Hi,

On Sun, 26 Aug 2007, Jeff King wrote:

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

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

quoted text
> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html