Re: git: a1097094c4c5 - main - newvers: Set explicit git revision length
Date: Sat, 14 Dec 2024 00:14:21 UTC
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.