Re: [PATCH] fast-(import|export): improve on the signature algorithm name

From: Elijah Newren <newren@gmail.com>
Date: May 28, 2025, 23:15 UTC
Message-ID: <CABPp-BFRhSB0zTY1m+gYOpfvmuTvN5Pu3STawJwx9P-ayJw6bA@mail.gmail.com>
In-Reply-To: <xmqq4ix4qtva.fsf@gitster.g>

On Wed, May 28, 2025 at 2:59 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 27 quoted lines

>
> Elijah Newren <newren@gmail.com> writes:
>
> > Often
> > when we have deprecated or changed an option our process was to first
> > produce an error and update documentation and wait a while, then go
> > and change the default after a sufficiently long time.  Here, we had
> > kind of stopped at just producing the error with no plans to take
> > another step.  If that was the route we took in the past, what makes
> > this considered a breakage and not the other changes we made?
> >
> > (Just curious, I'm not against this change.)
>
> What is wrong is the behaviour change in the original, which luckily
> is not in any released versions (except for 2.50-rc0, which should
> not count, as I think we should do this toning-down before -rc1).
>
> We used to silently ignore and strip commit signatures and that has
> always been the behaviour the existing users have relied upon; we
> started requiring these existing users to either explicitly pass
> --signed-c=strip or set an environmtne variable.  A new feature
> should be opt-in to make the transition smoother, but the topic did
> not follow that pattern.
>
> I view this last-minute band-aid patch that flips the default back
> to what it used to be as remedying that mistake in the original
> series.

An earlier version of the series did keep the stripping, but you were the one who objected (https://lore.kernel.org/git/xmqqfszbcazc.fsf@gitster.g/):

""" Why deliberate inconsistency? I am not sure "historically we did a wrong thing" is a good reason (if we view that silently stripping was a disservice to the users, aborting would be a bugfix). """

and later in the series (https://lore.kernel.org/git/xmqqim44fyjj.fsf@gitster.g/), you added:

""" Thanks. The "filter-repo already gets bug reports from the users" is a valuable input when deciding if it is reasonable to sell the behaviour change as a bugfix to our users. """

Personally, I kind of think abort makes more sense as the default -- at some point. So I'm curious if you've just changed your mind completely from before and are against changing the default at all, whether you think there's more steps that should be done before we change the default, or whether this new flag feeling incomplete and development related to it being slow moving means we should wait off until we have a better picture of where it'll end up and leave the defaults alone until we get there. (I'm kind of leaning towards the 3rd of those, but am curious if I'm misaligned with your vision.)