Re: [PATCH 1/4] sequencer: do not translate reflog messages

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Aug 19 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Fri, Aug 19 2022, Junio C Hamano wrote:
>>
>>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>>
>>>> Doesn't that also mean that the relevant functionality is now also (and
>>>> still?) broken on any repository where these translations ended up
>>>> on-disk?
>>>
>>> It may, but the first response to that problem is not to make the
>>> breakage in repositires worse by keep adding unparseable data to
>>> them.
>>
>> *nod*, but where is that breakage specifically?
>
> Set your LANG to something other than C and then run "git reflog"
> after running sequencer operations, and you'll see the same breakage
> that motivated Michael to send this patch set, I think.

Yes, I can see how and what we write to the reflog. But in order for
this to cause anything other than cosmetic breakage we'd need more than
that.

Or what do we mean by breakage here?

That it's broken because we intended for these to be LC_ALL=C, but they
weren't? Fair enough, but that's got a smaller scope.

Or that it's broken because we expected to not only write "rebase:
fast-forward" into the reflog, but to parse that out again, or to
e.g. parse the "rebase" part of it out as a command-name. I haven't
found *those* bits yet.

Of course we also have to worry about third-party software that expected
LC_ALL=C breaking. I'm just wondering if we have some code in git.git
that would also be similarly broken.

Because if we do it wouldn't be that hard to just hardcode all the
translations we shipped at that time in some array in the C code, and
not only parse out a "rebase: fast-forward", but also the German
etc. equivalent.