胡哲宁 <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 ;-)
