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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 17, 2021, 08:49 UTC
Message-ID: <xmqq35nv416j.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2111161227090.21127@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 8 quoted lines

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