git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Okhuomon Ajayi <okhuomonajayi54@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs
Date: Mon, 13 Oct 2025 20:00:13 -0700	[thread overview]
Message-ID: <xmqqecr6yypu.fsf@gitster.g> (raw)
In-Reply-To: <20251013174658.236940-1-okhuomonajayi54@gmail.com> (Okhuomon Ajayi's message of "Mon, 13 Oct 2025 18:46:58 +0100")

Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:

> Patch IDs in Git must always use SHA1, regardless of the repository's
> object hash. Previously, the code relied on `the_hash_algo` which could
> vary depending on the repository, and included a NEEDSWORK comment
> suggesting this should be fixed.

I do not think that is what the comment suggests to do.

Read it again:

    ... should be removed in favor of converting the code that
    computes patch IDs to always use SHA1.

There are code paths that compute patch IDs elsewhere, and they are
not immediately below the NEEDSWORK comment.  The code relies on
the_hash_algo and that is why the "hack" makes repo_set_hash_algo()
call.  The suggestion is to convert that code that hashes patch to
compute patch IDs not to use the_hash_algo that is repository
dependeant.  I think get_one_pathcid() function in the same file is
one of them.

> This patch updates the comment to clearly state that SHA1 is required
> for patch IDs and sets the hash algorithm to SHA1 if it is not already
> set. This ensures consistent computation of patch IDs in accordance
> with git-patch-id(1).

And if it is already set?  I think what your first paragraph claims
to be problematic is that case, and the patch does not touch that
case at all.

Blindly setting the_hash_algo to SHA-1 may not be the end of the
"solution", so whoever wants to work on this needs to be extra
careful.  If the code after this point, starting from the call to
generate_id_list() we see in the post context, need to touch any Git
objects in the current repository (e.g., to obtain patch text or
some configuration data), such accesses need to use the hash that
the repository uses.  Only the final "now we have this patch, and we
learned what the configuration says how we should compute the
patch-id.  Let's hash the patch text following the specified
algorithm" step should use SHA-1 as the hash algorithm.

Perhaps we are lucky that this program has *no* need to access
objects in the repository (my quick scan says this seems to work on
an external text file and does not generate diffs locally out of
objects), and it may not depend on configuration data coming from
any objects in the repository (there are some configuration variables
whose values are blob object names that instructs Git to read such
an object).  In such a case, then the solution may be to always
make the code ignore the_hash_algo and unconditionally using SHA1.

  reply	other threads:[~2025-10-14  3:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 17:46 [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs Okhuomon Ajayi
2025-10-14  3:00 ` Junio C Hamano [this message]
2025-10-14  8:04   ` Okhuomon Ajayi
2025-10-14 21:18 ` brian m. carlson
2025-10-14 22:29   ` Junio C Hamano
2025-10-14 22:49     ` brian m. carlson
2025-10-14 23:27       ` Okhuomon Ajayi
2025-10-15 13:37       ` Junio C Hamano
2025-10-15 13:59         ` Kristoffer Haugsbakk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqecr6yypu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=okhuomonajayi54@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).