Elijah Newren <newren@xxxxxxxxx> 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.
