Re: [PATCH] show-index: warn when falling back to SHA-1 outside a repository
- From
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
- Date
- Jan 30, 2026, 08:59 UTC
- Message-ID
- <20260130085949.253788-1-shreyanshpaliwalcmsmn@gmail.com>
- In-Reply-To
- <xmqq5x8k9g4b.fsf@gitster.g>
Show 22 quoted lines
> > When 'git show-index' is run outside of a > > repository and no hashing algorithm is > > specified via --object-format, it silently > > falls back to SHA-1, relying on the > > historical default. > > > > This works for existing SHA-1 based > > index files, but the behavior can be ambiguous > > and confusing when the input index file uses a > > different hash algorithm, such as SHA-256. > > > > Add a warning when this fallback happens > > to make the assumption explicit and to > > guide users toward using --object-format > > when needed. > > Line wrapping at 50 columns certainly makes the lines narrower than > 80 column limit, but let's not go to the extreme. We recommend that > the lines are still less than 80-columns after being quoted a few > times in e-mail exchange (as you can see, I lost 2 columns by > quoting once in the above), which means that around ~70 columns is > the practical fill-column.
Understood. I Will make sure to keep message wrapping around ~70 columns.
Show 19 quoted lines
> > Additionally, wrap user-facing die() messages
> > with _() so they can be translated via gettext.
>
> It is somewhat distracting that such "while at it" changes dominate
> this ~100-line patch, whose "primary change" is a mere three lines
> we can see here:
>
> > - if (!the_hash_algo)
> > + if (!the_hash_algo) {
> > + warning(_("assuming SHA-1; use --object-format to override"));
> > repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
> > + }
>
>
> Can we push the "while at it" message changes to a separate patch, a
> preparatory clean-up, on top of which another primary patch adds the
> above warning? Alternatively, have the primary patch that adds the
> above warning and does nothing else, followed by a post clean-up patch
> to tweak the existing error messages?Yes, agreed. I’ll split the changes into separate patches again, as in the original RFC series, and send a v2.
Best, Shreyansh