Re: [PATCH] find_unique_abbrev(): honor caller-supplied "len" better

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2011, 01:33 UTC
Message-ID: <7vmxl21lwr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTikPxSspRFQWke4=u55cmmHw8NsyizeH2gL1kD0y@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 11 quoted lines

> IOW, try your example thing not just with "master", but with two
> extreme commits. For example, try
>
>   git -c core.abbrevguard=2 rev-parse --short=5 83c3c622
>   git -c core.abbrevguard=2 rev-parse --short=4 979f7929
>
> and tell me what you get. I _think_ you should get 7 digits for the
> first case, and 8 digits for the second one. Even though you "asked"
> for a longer name in the first case, and you had the same abbrevguard.
>
> See what I'm saying? I think that's just insane.

Hmph, why?

That 979f79 one already have enough other objects with similar names, so compared to 83c3c that doesn't, it is natural that you would need more digits to protect its uniqueness, no? The result shouldn't be affected by the value of "short" as long as it is not long enough, as that is merely specifying "at least this many letters".

Another thing to realize is that without abbrevguard with the code before the configuration was introduced, you would get very similar results. With --short=5, you would get 5 letters for 83c3c622 and with --short=4, you would still need 8 letters for 979f7929. Because either of these values are not long enough and it is merely a way to specify "at least this many letters".

If we don't care about uniqueness, we can just truncate at the number of characters specified by the "len" without doing anything else. That would give us an output of uniform length without the uniqueness guarantee, and "git describe" output cannot even be fed back to git running in the same repository immediately after it is obtained. I don't think that is what we want.