Re: [PATCH 2/2] describe doc: remove '7-char' abbreviation reference

> On Sat, Apr 06 2019, Philip Oakley wrote:
>
>> While the minimum is 7-char, the unambiguous length can be longer.
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> noticed while looking int the Git-for-Windows patch thicket -
>> was looking for the ~n^m style!
>> ---
>>   Documentation/git-describe.txt | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
>> index ccdc5f83d6..a88f6ae2c6 100644
>> --- a/Documentation/git-describe.txt
>> +++ b/Documentation/git-describe.txt
>> @@ -139,7 +139,7 @@ at the end.
>>
>>   The number of additional commits is the number
>>   of commits which would be displayed by "git log v1.0.4..parent".
>> -The hash suffix is "-g" + 7-char abbreviation for the tip commit
>> +The hash suffix is "-g" + unambiguous abbreviation for the tip commit
>>   of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
>>   The "g" prefix stands for "git" and is used to allow describing the version of
>>   a software depending on the SCM the software is managed with. This is useful
> Both the old/new version are subtly wrong. Whether the new one is better
> is another matter.
>
> First, there's more places we mention the now-incorrect 7 characters, at
> least these (one of which you're fixing). Found by grepping for ' 7 '
> and '7.*abbr':
>
>      Documentation/git-branch.txt-181---abbrev=<length>::
>      Documentation/git-branch.txt-182-       Alter the sha1's minimum display length in the output listing.
>      Documentation/git-branch.txt:183:       The default value is 7 and can be overridden by the `core.abbrev`
>      Documentation/git-branch.txt-184-       config option.
>      Documentation/git-describe.txt-65---abbrev=<n>::
>      Documentation/git-describe.txt:66:      Instead of using the default 7 hexadecimal digits as the
>      Documentation/git-describe.txt-67-      abbreviated object name, use <n> digits, or as many digits
>      Documentation/git-ls-tree.txt-93-Object size identified by <object> is given in bytes, and right-justified
>      Documentation/git-ls-tree.txt:94:with minimum width of 7 characters.  Object size is given only for blobs
>      Documentation/git-ls-tree.txt-95-(file) entries; for other entries `-` character is used in place of size.
>      Documentation/gittutorial-2.txt-44-
>      Documentation/gittutorial-2.txt:45:What are the 7 digits of hex that Git responded to the commit with?
>      Documentation/gittutorial-2.txt-46-
>      [...]
>      Documentation/gittutorial-2.txt-52-name), and that the contents of a Git object will never change (since
>      Documentation/gittutorial-2.txt:53:that would change the object's name as well). The 7 char hex strings
>      Documentation/gittutorial-2.txt-54-here are simply the abbreviation of such 40 character long strings.
>
> It was never correct that we'd pick 7 characters, we'd *try* that before
> e6c587c733 ("abbrev: auto size the default abbreviation", 2016-09-30)
> but would pick a longer one if it was unambiguous.
>
> Whereas "unambiguous abbreviation" isn't correct either, and arguably
> less correct. At least 7 is what we *still* pick as a fallback in lieu
> of the auto-sizing, but just "unambiguous abbreviation" implies that in
> a repo with some 10 objects we might show just one character, or that
> we'd post-e6c587c733 pick say 7 characters in a repository where it *is*
> unambiguous but where we've auto-sized to 12.
>
> I've been meaning to follow-up on
> https://public-inbox.org/git/20190204161217.20047-1-avarab@gmail.com/
> where I among other things wanted to just have these instances all say
> "commits will be abbreviated as described in XYZ in linkgit:<something>"
> and summarize what happens there.
>
> I don't mind if this goes in, I mainly wrote this E-Mail as a brain dump
> since it jolted my memory on the topic, and so that I could dig it up
> later & see how I intended to follow-up on those #leftoverbits