> On Dec 19, 2024, at 5:21 AM, Ed Maste <ema...@freebsd.org> wrote:
>
> On Wed, 18 Dec 2024 at 12:12, Gleb Smirnoff <gleb...@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