Re: git 2.46.0 crashes when trying to verify-pack outside of a repo

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 3, 2024, 15:52 UTC
Message-ID: <xmqqv7zcn39t.fsf@gitster.g>
In-Reply-To: <ZtXCBcn6WZIHr65b@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 7 quoted lines

>> I'd personally recommend just requiring the `--object-format=` option,
>> but of course if you want to write pack v5, don't let me stop you.
>
> Well, in the context of this issue I'd definitely aim for the easier fix
> first. Regardless of whether or not we introduce v5, we'd still have to
> address the underlying issue for repositories that do not (yet) have v5
> packfiles.

I would be hesitant to reroactively tightening the rules, though. If a tool has worked well for those who can and wants to assume a hash function (because it has been the default, or perhaps because the user configured the tool as such) even outside a repository, such a tightening is a regression. If such a change is done to avoid triggering a data corrupting bug, we may be able to come up with a valid justification, but on the other hand, to discourage certain uses of the tool, even if the discouraged use is an insecure one, feels a bit too opinionated for a tool. It has the same smell as updating the "md5sum" tool to discourage the use of the function so that it always exits with 1 (after computing and showing the hash) or something silly like that.

I am not saying that it is bad for a tool to be opinionated. When we design a new feature, it is part of the design process to make sure that use of the feature encourages use of better workflows.

But disabling what has worked to user's expectation so far is a bit different story.