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

[Elijah Newren <newren@gmail.com>]

On Wed, May 28, 2025 at 2:59 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.)