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@xxxxxxxxx> 于2021年1月19日周二 上午5:31写道：
>
> 胡哲宁 <adlternative@xxxxxxxxx> 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 ;-)
