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

[Patrick Steinhardt <ps@pks.im>]

On Wed, Jan 21, 2026 at 04:01:47PM +0530, Shreyansh Paliwal wrote:
> > 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.

That would be a regression for users that currently _can_ run
git-show-index(1) outside of a repository with a SHA-1 based index. It's
not going to be a common use case, but I wouldn't be surprised if there
was at least one user out there that we'd break with such a change.

Patrick