Show 34 quoted lines
> On Thursday 20 August 2009, Junio C Hamano wrote:
>> Johan Herland <johan@herland.net> writes:
>>>> - $sub1sha1 sub1 (${sub1sha1:0:7})
>>>> - $sub2sha1 sub2 (${sub1sha1:0:7})
>>>> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
>>>> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
>>> Typo (both in the original, and the patch), should be:
>>> $sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
>>>
>>>> $sub3sha1 sub3 (heads/master)
>>>> EOF
>>> Otherwise:
>>>
>>> Acked-by: Johan Herland <johan@herland.net>
>> Hmm, what does the command use to shorten these object names? It may be
>> safer and more correct to use "rev-parse --short" in case these object
>> names were ambigous in their first 7 hexdigits.
>
> git submodule status (which is what we're testing here) uses
> 'git describe' to generate the short object name (see
> set_name_rev in git-submodule.sh). In this case, it falls back
> to 'git describe --all --always', which calls find_unique_abbrev()
> on the SHA1. 'git rev-parse --short' ends up calling the same
> find_unique_abbrev(), so I guess it is better to use it here.
>
> Try this instead:
>
> From: Johan Herland <johan@herland.net>
>
> Subject: [PATCH] t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
>
> The substring expansion notation is a bashism that we have not so far
> adopted. Use 'git rev-parse --short' instead, as this also handles
> the case where the unique abbreviation is longer than 7 characters.