Re: [PATCH 1/3] show-index: implement automatic hash detection

From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
Date: Jan 21, 2026, 10:31 UTC
Message-ID: <20260121103431.793004-1-shreyanshpaliwalcmsmn@gmail.com>
In-Reply-To: <aXCJp_rGPetsXE8J@pks.im>

Show 14 quoted lines

> 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