Re: fz/rebase-msg-update (2023-02-27)

[Fangyi Zhou <me@fangyi.io>]

On Wed, 8 Mar 2023 at 20:59, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

(Apologies for sending again, forgot to reply all in the previous mail)

Thanks for the context. I misunderstood your earlier email and I
appreciate your comments. I understand your position as the maintainer
and I'm fine with the patch not being included.
I would like to politely point out that l10n contributors usually
start working when rc0 is tagged, and occasionally there are small
inconsistencies that are found during the l10n process and patches are
sent to address them. I've done so in the past without issues. I would
argue there needs to be a way for those consistency fixes to be
included (I sent my patch after rc0, before rc1 is tagged). l10n
contributors usually need to revise after rc1/rc2 are tagged anyway.

Thanks,
Fangyi

On Wed, 8 Mar 2023 at 20:59, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> 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.