Re: [PATCH 3/4] t5604: do not expect that HEAD is a valid tagname

From: Jeff King <peff@peff.net>
Date: Dec 5, 2024, 20:25 UTC
Message-ID: <20241205202537.GD2629822@coredump.intra.peff.net>
In-Reply-To: <xmqq34j5h7v9.fsf@gitster.g>

On Tue, Dec 03, 2024 at 10:29:14AM +0900, Junio C Hamano wrote:

Show 19 quoted lines

> I have "git one" (and "git who") aliased to this script:
> 
>     $ cat $(type --path git-onewho)
>     #!/bin/sh
>     if sha1=$(git rev-parse -q --verify "$1")
>     then
>             git show --date=short -s --abbrev=8 --pretty='format:%h (%s, %ad)' "$1"
>     else
>             git log -1 --format="%aN <%aE>" --author="$1" --all
>     fi | tr -d "\012"
>     $ git help one
>     'one' is aliased to 'onewho'
>     $ git help who
>     'who' is aliased to 'onewho'
>     
> so that I can say "\C-u ESC ! git one HEAD" (or "git one peff")
> while writing a piece of e-mail.  I can drop --abbrev=8 from there
> but the machinery knows to bust that limit if it is necessary to
> ensure uniqueness, so ...

Yeah, I have something similar. IMHO a manual --abbrev there is working against your goal.

We do increase that to find a unique answer, but that is not very future-proof; it is only extending by one character taking into account what objects you have _now_. It might not be true for somebody else's repo with more objects, or even your own repo in the near future.

The auto-scaling of core.abbrev done by default these days also suffers from that problem (it can only count how many objects you have now, not how many you expect to have a year from now). But I think our heuristics there give a bit higher safety margin for future-proofing the values.

-Peff