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

[胡哲宁 <adlternative@gmail.com>]

Thank you very much for your answer,I also learned a lot from it, then
I will use the description of "suppress duplicate entries".

Junio C Hamano <gitster@pobox.com> 于2021年1月19日周二 上午5:31写道：
>
> 胡哲宁 <adlternative@gmail.com> writes:
>
> > 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 ;-)