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

From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Jiang Xin" <worldhello.net@gmail.com>,
	"Git List" <git@vger.kernel.org>,
	"Jiang Xin" <zhiyou.jx@alibaba-inc.com>,
	"Alexander Shopov" <ash@kambanaria.org>,
	"Jordi Mas" <jmas@softcatala.org>,
	"Matthias Rüster" <matthias.ruester@gmail.com>,
	"Jimmy Angelakos" <vyruss@hellug.gr>,
	"Christopher Díaz" <christopher.diaz.riv@gmail.com>,
	"Jean-Noël Avila" <jn.avila@free.fr>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	"Alessandro Menti" <alessandro.menti@alessandromenti.it>,
	"Gwan-gyeong Mun" <elongbug@gmail.com>, Arusekk <arek_koz@o2.pl>,
	"Daniel Santos" <dacs.git@brilhante.top>,
	"Dimitriy Ryazantcev" <DJm00n@mail.ru>,
	"Peter Krefting" <peter@softwolves.pp.se>,
	"Emir SARI" <bitigchi@me.com>,
	"Trần Ngọc Quân" <vnwildman@gmail.com>,
	"Fangyi Zhou" <me@fangyi.io>, "Yi-Jyun Pan" <pan93412@gmail.com>
Subject: Re: [PATCH] Makefile: dedup git-ls-files output to prevent duplicate targets
Date: Thu, 26 May 2022 10:18:00 -0700	[thread overview]
Message-ID: <xmqq8rqo1ad3.fsf@gitster.g> (raw)
In-Reply-To: <220526.86tu9c625s.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Thu, 26 May 2022 12:00:04 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I pointed out then that with --sort-by-file added we:
>
>  * Don't group the translations by C/SH/Perl anymore
>  * Change the sort order within files, to be line/sorted instead of
>    line/order (i.e. first occurring translations first)
>
> I suggested then to just use $(sort) on the respective lists.
>
> So why not just:
>
>  1. Switch to the $(FOUND_C_SOURCES) (good)
>  2. Filter that by C/Perl/SH as before (just a simple $(filter)
>  3. $(sort) that (which as noted, also de-dupes it)
>
> Then we don't have any of the behavior change of --sort-by-file, and we
> don't have to carefully curate the ls-files/find commands to not include
> duplicates (although as seen here that seems to have been a useful
> canary in the "find" case).

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 ;-)