On 12/13/24 19:14, Ed Maste wrote:
On Fri, 13 Dec 2024 at 09:53, John Baldwin <j...@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 <p...@patmaddox.com>
AuthorDate: 2024-12-13 05:28:18 +0000
Commit:     Ed Maste <ema...@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 <p...@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


Reply via email to