Re: [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs

Hi Junio, Brian,

Thanks a lot for the detailed explanations  this gave me a much better
understanding of the history behind patch-id and why the hash choice
isn’t straightforward.

I see now that just forcing SHA-1 isn’t ideal since patch-id already
uses the repo’s hash in SHA-256 repos. I’ll take another look at how
the computation works in the other paths and think about how to handle
it better, maybe by adding an option or clarifying the behavior.

Really appreciate you both taking the time to explain  I’m learning a
lot from this.

On Tue, Oct 14, 2025 at 11:49 PM brian m. carlson
[off-list ref] wrote:

On 2025-10-14 at 22:29:34, Junio C Hamano wrote:

quoted

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