From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
Date: Fri, 30 Jan 2026 08:59:22 GMT
Subject: Re: [PATCH] show-index: warn when falling back to SHA-1 outside a repository
Message-ID: <20260130085949.253788-1-shreyanshpaliwalcmsmn@gmail.com>
In-Reply-To: <xmqq5x8k9g4b.fsf@gitster.g>

> > 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.

> > 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