From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail•com>
To: git@vger•kernel.org
Cc: gitster@pobox•com, ps@pks•im
Subject: Re: [PATCH 1/3] show-index: implement automatic hash detection
Date: Wed, 21 Jan 2026 16:01:47 +0530 [thread overview]
Message-ID: <20260121103431.793004-1-shreyanshpaliwalcmsmn@gmail.com> (raw)
In-Reply-To: <aXCJp_rGPetsXE8J@pks.im>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1887 bytes --]
> On Tue, Jan 20, 2026 at 10:07:42AM -0800, Junio C Hamano wrote:
> > Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail•com> writes:
> > > @@ -71,6 +60,40 @@ int cmd_show_index(int argc,
> [snip]
> > By the way, what happens if we find SHA-256 also broken and end up
> > choosing another hash function that is 256-bit wide in the next hash
> > revamp?
>
> Yeah, agreed. The index unfortunately does not carry sufficient info to
> clearly identify the hash function that is in use, and second-guessing
> via the hash length doesn't really seem like a sensible solution to me.
> If we cannot tell for sure what the hash is, then we should rather ask
> the user to specify the object format. And in fact we already do that,
> as we have the `--object-format=` option for git-show-index(1).
Yes this is exactly why I was peculiar about this patch and the
TODO comment, also why I sent it out as an RFC.
I initially assumed that in the near future we’re unlikely to move away
from SHA-256 to another hash, but I agree that relying
on hash length is still a heuristic that won't be a good approach
in the long term as well as it creates ambiguity in the large files
containing 64-bit offsets.
So should we drop this thought entirely and just make sure
that if git show-index is run outside a repo,
it should throw an error asking the the user
to use --object-format option rather than silently
falling back to SHA-1 which is the current approach.
> I think if we wanted to fix properly this we should rather introduce
> index v5 with a header that encodes the hash used by it. Like that we
> wouldn't have to guess anymore. Whether the hassle is worth it might be
> a different question though.
Yes, I agree that the best fix for long term would be an index
that contains header encoded with hash, but I guess
it would require many changes in the whole pack index flow.
Best,
Shreyansh
next prev parent reply other threads:[~2026-01-21 10:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 14:05 [RFC][PATCH 0/3] show-index: modernize and implement auto-detection of hash algorithm Shreyansh Paliwal
2026-01-20 14:05 ` [PATCH 1/3] show-index: implement automatic hash detection Shreyansh Paliwal
2026-01-20 18:07 ` Junio C Hamano
2026-01-21 8:09 ` Patrick Steinhardt
2026-01-21 10:31 ` Shreyansh Paliwal [this message]
2026-01-23 7:22 ` Patrick Steinhardt
2026-01-23 16:08 ` Shreyansh Paliwal
2026-01-23 20:29 ` brian m. carlson
2026-01-21 10:28 ` Shreyansh Paliwal
2026-01-20 14:05 ` [PATCH 2/3] show-index: use gettext wrapping in error messages Shreyansh Paliwal
2026-01-20 14:05 ` [PATCH 3/3] show-index: remove global state variables Shreyansh Paliwal
2026-01-21 10:39 ` Phillip Wood
2026-01-21 12:47 ` Shreyansh Paliwal
2026-01-21 17:23 ` Junio C Hamano
2026-01-29 15:36 ` [PATCH] show-index: warn when falling back to SHA-1 outside a repository Shreyansh Paliwal
2026-01-29 23:03 ` Junio C Hamano
2026-01-30 8:59 ` Shreyansh Paliwal
2026-01-29 23:12 ` brian m. carlson
2026-01-30 9:04 ` Shreyansh Paliwal
2026-01-30 13:40 ` Patrick Steinhardt
2026-01-30 17:01 ` Junio C Hamano
2026-01-30 15:31 ` [PATCH V2 0/2] show-index: add warning and wrap error messages with gettext Shreyansh Paliwal
2026-01-30 15:31 ` [PATCH V2 1/2] show-index: warn when falling back to SHA-1 outside a repository Shreyansh Paliwal
2026-01-30 15:31 ` [PATCH V2 2/2] show-index: use gettext wrapping in user facing error messages Shreyansh Paliwal
2026-01-30 17:07 ` [PATCH V2 0/2] show-index: add warning and wrap error messages with gettext Junio C Hamano
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=20260121103431.793004-1-shreyanshpaliwalcmsmn@gmail.com \
--to=shreyanshpaliwalcmsmn@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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