On 2025-10-14 at 22:29:34, Junio C Hamano wrote:
I do not quite agree with that, as SHA-1 in patch-id is merely used
as "a hash function with good distribution that we happened to have
handy access to" without any security requirement. Being able to
compare patch IDs computed long ago stored somewhere with patch ID
on a patch that claims to be freshly written and find them the same
to say "you know, somebody wrote exactly the same patch 7 years ago"
would be valuable, and we do not want to lose it even when you
happen to store your payload in a SHA-256 repository.
I think that's too late, though. We already use SHA-256 in a SHA-256
repository, so people already expect that to work now and in the future.
The time to make this decision would have been in 2020 with Git 2.29,
but we now have people who will be using SHA-256 patch IDs and we need
to support them.
We have also specifically discussed in the past people eventually
wanting to compile Git without SHA-1 support at some point in the future
for regulatory or compliance reasons, so we should full well expect that
to happen and we'll need to be agile about the algorithm. SHA-1 will
definitely disappear from at least some distributions of Git in the
future.
Given that context, I think allowing the specification of an algorithm
would allow people to say, "Yes, I am in a SHA-256 repository, but I
want SHA-1," or vice versa, which would work with your use case better.
--
brian m. carlson (they/them)
Toronto, Ontario, CA