Re: git: a1097094c4c5 - main - newvers: Set explicit git revision length

On 12/13/24 19:14, Ed Maste wrote:
> On Fri, 13 Dec 2024 at 09:53, John Baldwin <jhb@freebsd.org> wrote:
>>
>> On 12/13/24 08:06, Ed Maste wrote:
>>> The branch main has been updated by emaste:
>>>
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=a1097094c4c5d810287aca092f4ab5f9f86a426a
>>>
>>> commit a1097094c4c5d810287aca092f4ab5f9f86a426a
>>> Author:     Pat Maddox <pat@patmaddox.com>
>>> AuthorDate: 2024-12-13 05:28:18 +0000
>>> Commit:     Ed Maste <emaste@FreeBSD.org>
>>> CommitDate: 2024-12-13 13:06:10 +0000
>>>
>>>       newvers: Set explicit git revision length
>>>
>>>       The --short flag is configurable. Setting an explicit length supports
>>>       reproducible builds.
>>>
>>>       Signed-off-by: Pat Maddox <pat@patmaddox.com>
>>>       Reviewed by: emaste, imp
>>>       Differential revision: https://github.com/freebsd/freebsd-src/pull/1547
>>
>> Hmm, this seems to defeat the purpose of the --short flag.  I think if you want
>> this to be reproducible you just need to use the full hash.  If we get enough commits
>> that git thinks we need a longer short hash, then truncating the hash to a shorter
>> length here is a bug.
> 
> --short with no explicit length is most likely to result in
> nonreproducibility due to a user setting a different default short
> length in their git config. Note that --short won't truncate and
> result in a conflict, it will just exceed the specified length if
> necessary. For example,
> 
> $ git rev-parse --short=4 freebsd/main
> 926905
> 
> It's possible for this to result in occasional trouble when attempting
> to reproduce an older build (if --short=12 is sufficient today, but a
> future commit introduces a conflict), but I don't think it's a large
> concern. We could increase it to 13 or 14 now

Well, the default --short length is not based on when Git detects a conflict,
it's a function of the total number of objects in a repository.  This means
it may be different if you just fetch some other remote with many revisions
in the same clone for example.  The thing I don't know is what formula git
uses and how close we are/aren't to rolling over to 13 just with src.git
alone.  It seems to me that the most fool-proof thing though if we really
want reproduciblility is to drop --short entirely.  Short of that, if
you can tell git to run in a mode where it ignores user configuration (though
I don't see a way to do that).

-- 
John Baldwin