Re: [PATCH v4 3/3] ls-files: add --deduplicate option

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2021, 21:31 UTC
Message-ID: <xmqqczy2j5k0.fsf@gitster.c.googlers.com>
In-Reply-To: <CAOLTT8QnhNqnJCgiqOZnd9cjxicAuk2Js1GKdHEJD_XK15UU+Q@mail.gmail.com>

胡哲宁 <adlternative@gmail.com> writes:

Show 5 quoted lines

> Here I am thinking about the role of this "--deduplicate" is to
> suppress duplicate filenames rather than duplicate entries. Do you
> think I should modify this sentence?
>
>> > OPT_BOOL(0,"deduplicate",&skipping_duplicates,N_("suppress duplicate entries")),

I see no strong need to. One set of output entries from "ls-files" may say

    $ git ls-files -u
    100644 536e55524db72bd2acf175208aef4f3dfc148d41 1	COPYING
    100644 536e55524db72bd2acf175208aef4f3dfc148d43 3	COPYING

and these three "entries" are not duplicates. Another set of output entries may say

    $ git ls-files COPYING
    COPYING
    COPYING
    COPYING

and these output entries are duplicates. If you deduplicate the latter but not the former, then "suppress duplicate entries" is exactly what you are doing, I would think.

And if you are asked to show entries that would look like this in a not-deduplicated form:

    $ git ls-files -u
    100644 536e55524db72bd2acf175208aef4f3dfc148d41 1	COPYING
    100644 536e55524db72bd2acf175208aef4f3dfc148d41 1	COPYING
    100644 536e55524db72bd2acf175208aef4f3dfc148d43 3	COPYING

"suppressing duplicates" would give us the first entry and drop the second entry that is identical to the second entry, I would think [*1*].

So "duplicate entries" would probably be more correct description of what we want to happen than "duplicate filenames".

[Footnote]

*1* Multiple "common ancestor" versions at stage #1 for the same
    path is not an error.  That is how "merge-resolve" expresses
    criss-cross merge where multiple merge-bases exist.

    Multiple "their" versions at stage #3 for the same path is not
    an error, and "merge-octopus" should use it to express contents
    from histories being merged into ours, but the implementation of
    the octopus strategy does not use this feature of the index.

    Multiple "our" versions at stage #2 by definition should not
    happen ;-)