On Fri, Aug 19 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> On Fri, Aug 19 2022, Junio C Hamano wrote: >> >>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
