Re: [PATCH] Makefile: dedup git-ls-files output to prevent duplicate targets

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

On Thu, May 26 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> Does "--sort-by-file" really mean that?
>>>
>>> The option is documented to sort output by file location, but does
>>> it mean without the option (i.e. default), there is no guarantee in
>>> the output order?  Or are we sure that the output is sorted by the
>>> order of input files, and that is guaranteed to hold in the future?
>>>
>>> If we are depending on certain ordering of the output produced by
>>> gettext suite of programs, I would keep the option, regardless of
>>> what we do to the input to them, if I were running the i18n part of
>>> this project.
>>>
>>> But I am not, so I would not complain if --sort-by-file is dropped
>>> against my advice ;-)
>>
>> The gettext docs are pretty light on the subject, but the default "sort
>> order" is none at all. I.e. it'll just inhale source and spew out
>> translations in the order you feed them to xgettext.
>>
>> So in order of input files, and then in order they're seen in the
>> program.
>>
>> I don't think that's ever going to change.
>
> OK, so as long as make's notion of $(sort) and gettext suite's
> notion of --sort-by-file are the same.

They're not, I mean $(sort) and xgettext's *default* behavior are the
same, but the --sort-by-file is not only a sort by file, it also affects
intra-line-number sorting, although that's an admittedly obscure case
(we have <10 messages where it matters, I think).

> , we didn't make any change, and even if they were different, since
> there is no version of Git that uses "--sort-by-file" while preparing
> the po and pot files, it still is OK.

Well, it would be OK in any case, this is just how we prepare the
git.pot file, but it does affect diff churn eventually in the *.po
files.

> As long as make's $(sort) is as stable as gettext
> suite's "--sort-by-file" across developer locales (and our filenames
> are ascii-only and hopefully will stay that way), everybody will get
> the messages in the same order either way (or we would have the same
> problem so switching from --sort-by-file to $(sort) is not making
> anything worse).

FWIW we can't in the general case rely on the Makefile's $(sort) working
the same way across our platforms, but I don't think it matters in this
case. IIRC there's versions of one Windows setup or another (this was
via CI) where "-" at least (the purely ASCII one) sorts differently.

I ran into that in some Makefile experiments where I wanted to use
$(sort) to assert that our various hardcoded lists were in sorted order
already.