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

胡哲宁 [off-list ref] 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?

quoted

quoted

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 ;-)

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 [off-list ref] 于2021年1月19日周二 上午5:31写道：

胡哲宁 [off-list ref] writes:

quoted

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?

quoted

quoted

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 ;-)