Junio C Hamano <gitster@xxxxxxxxx> writes: >>> Besides, localizaiton teams are already working on what has been >>> in 'master'; it disrupts their workflow to change end-user message >>> under them. >> >> The patch fixes a newly added i18n string, not the option itself, >> see >> https://github.com/git-l10n/pot-changes/blob/pot/main/2023-02-04.diff >> I found the issue while conducting the localisation for v2.40.0. > > Exactly. That's not a regression. During -rc period is when we are supposed to concentrate on regression fixes, and I am not strongly inclined to merge it, but merging it would not be _too_ bad, either. If we ship the final without the patch, what happens to users in the C locale is that they may see a message that says that the rebase.autosquash variable is incompatible with use of 'rebase' via the apply backend. If they then inspect their configuration with "git config rebase.autosquash", they will sure find it set, and nobody gets hurt. Users in locales other than C may get the same message in their language, and again, there is no harm done. If we ship the final with the patch, users will see the message about rebase.autoSquash variable if they are in the C locale or locale whose translation can be updated in time, and their inspection of "git config rebase.autoSquash" would show that the configuration is there. But it would equally well worked if they said "git config rebase.autosquash". IOW, your "hotfix" may be fixing something that is no big deal in practice, even though it would have been much better if the original patch was done that way for consistency. The only losers if we merge the patch in the last hour before the release are those users in locales whose translation is not adjusted in time. They will see the message about rebase.autoSquash variable untranslated. So, I dunno. To me, merging the topic as part of the ~20 other topics slated for 'master' post 2.40 release looks like much better than hastily merging it down before the release. Thanks.
