Re: [PATCH/RFC] Makefile: dedup list of files obtained from ls-files

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 23, 2019, 01:18 UTC
Message-ID: <xmqq8sw17c3q.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <d869060a-a731-ff1d-3131-a146078fcf88@ramsayjones.plus.com>

Ramsay Jones <ramsay@ramsayjones.plus.com> writes:

Show 9 quoted lines

>> FWIW, after reading your commit message my thoughts immediately turned
>> to "why can't ls-files have a mode that outputs each just once", but
>> then ended up at the same place as your patch: it's not that hard to
>> just de-dup the output.
>
> My immediate thought was "that is simply a bug, no?" :-D
>
> I haven't used 'git ls-files' that much, so it's no great surprise
> that I had not noticed it odd behaviour!

Yup, the real issue is that ls-files uses exactly the same code for tagged output, output with stage numbers and just plain list of paths, so as we saw in the motivating use case for this patch, unmerged paths give us one source of duplication when we are asking for list of paths without stages.

It also considers, IIRC, deletion is merely one of the forms of modifications, so asking it to list modified paths and deleted paths at the same time would give you another source of duplication.

Perhaps not-so-low-hanging fruit miniproject would be to teach "ls-files" a new "--dedup" option that does two things:

 * When -m and -d are asked at the same time, ignore '-d', because
   '-d' will give duplicates for subsets of what '-m' would show
   anyway; and

 * When neither -s nor -u is given, do not show the same path more
   than once, even the ones with multiple stages.

Perhaps it is safe to leave a #leftoverbits mark for the above, now that two people in addition to I noticed that the behaviour is less than ideal.