Subject: Re: [PATCH] name-rev: prefer shorter names over following merges

From: Junio C Hamano <[email-masked]>
Date: Wed, 17 Nov 2021 00:49:08 -0800

Johannes Schindelin <[email-masked]> writes:

> Thank you. As you most likely figured out, that magic weight was
> introduced by me, in ac076c29ae8 (name-rev: Fix non-shortest description,
> 2007-08-27). And indeed the motivation was to keep the name as short as
> possible.
>
> Technically, your solution does not fix the problem fully, as we still do
> not determine the _shortest possible_ name. Having said that, I think your
> patch improves the situation dramatically, so: ACK!

It really depends on how you define "short".  Is v1.0~11 and v1.0~99
the same length and v1.0~100 a bit longer than these two?

I wonder what happens if we counted what the proposed commit log
calls "segments" and nothing else, e.g.

    v2.32.0~1471^2			has 2 segments ("~1471", "^2")
    v2.32.0~43^2~15^2~11^2~20^2~31^2    has 10 segments

and use number of hops only for breaking ties, instead of giving a
magic weight and trying to count both hops and segments.

In any case, this seems to give us a much better results than the
current code, so let's take it and leave further futzing outside the
scope.

Thanks.