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

> On Dec 19, 2024, at 5:21 AM, Ed Maste <emaste@freebsd.org> wrote:
> 
> On Wed, 18 Dec 2024 at 12:12, Gleb Smirnoff <glebius@freebsd.org> wrote:
>> 
>> E> The status quo of --short=12 should be fine for quite some time.
>> 
>> AFAIU John's concern is that you can't guarantee a reproducible build from a
>> "dirty" repository.  A repository that has more branches than just the official
>> ones.  I just make a quick check on Netflix repo, that has both the current
>> FreeBSD history and the before-the-official-git history together, as well as
>> splitted ports subdirectories and of course our own stuff.  For short hashes
>> there are roughly 2x more ambiguities than for a "clean" repo.  Apparently
>> chance of collision on a long hash is also doubled.
> 
> I suspect the six or seven character hashes I listed are still unique
> in your repository. If not, adding one more character to get to seven
> or eight will be enough. Pick a release and give `git rev-parse
> --verify --short=1 <hash>` a try in your repo -- I'm sure you'll get a
> unique short hash that's still much shorter than 12 characters.


Just a reminder, we also have git_cnt, so even a combination of non-uniq
short git hash and `git_cnt` is still sufficient to spot which version was built from.

So I do not think we need pay much concern with this, unless we drop `git_cnt`.

Best regards,
Zhenlei