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

From: Junio C Hamano <[email-masked]>
Date: Thu, 26 May 2022 12:00:29 -0700

Ævar Arnfjörð Bjarmason <[email-masked]> 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, 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.  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).