From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail•com>
To: git@vger•kernel.org
Cc: gitster@pobox•com, ps@pks•im
Subject: Re: [PATCH] show-index: warn when falling back to SHA-1 outside a repository
Date: Fri, 30 Jan 2026 14:29:22 +0530 [thread overview]
Message-ID: <20260130085949.253788-1-shreyanshpaliwalcmsmn@gmail.com> (raw)
In-Reply-To: <xmqq5x8k9g4b.fsf@gitster.g>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1917 bytes --]
> > 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
next prev parent reply other threads:[~2026-01-30 9:00 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
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 [this message]
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=20260130085949.253788-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