builtin/ls-files.c:add git ls-file --dedup option #832
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Please do not repeat the commit message in the first comment (which will be used as cover letter). Also: I thought the idea was to deduplicate entries automatically unless Finally, if you add the line |
@dscho Thanks,your repeat make me feel that i'm not alone😬 . I have changed my comment message with the issue url (should I rewrite my commit message too?but if I use git commit --amend && git push -f will it generate duplicate record in this push request?). From a technical point of view, There may be duplicate entries in a three-way merge. If we don’t use git ls-files -s or git ls-files -u (-u force contains -s), The --dedup I write now is to remove duplication in the case of the remaining (show_cached || show_deleted || show_modified) (Is my thinking incomplete?) |
It might, but that's a good thing, no?
My thinking is that it is not useful in the remaining cases to confusingly show multiple, identical entries. (When calling with But you should take this discussion to the mailing list, I am not a gatekeeper. In other words, once you feel confident that this patch is good, feel free to |
|
/submit |
|
Submitted as pull.832.git.1609923182451.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
Ok,I understand that now ! |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): |
|
User |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
/submit |
|
Submitted as pull.832.v2.git.1610116600.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -13,6 +13,7 @@ SYNOPSIS | |||
| (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* | |||
There was a problem hiding this comment.
On the Git mailing list, Eric Sunshine wrote (reply to this):
On Fri, Jan 8, 2021 at 9:36 AM ZheNing Hu via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> builtin:ls-files.c:add git ls-file --dedup option
This subject concisely explains the purpose of the patch. That's good.
A more typical way to write it would be:
ls-files: add --dedup option
> This commit standardizes the code format.
Fixing problems pointed out by reviewers is good. Normally, however,
when you submit a new version of your patch or patch series, you
should apply these fixes directly to the patch(es) which introduced
the problems in the first place rather than adding one or more
additional patches to fix problems introduced in earlier patches. To
do this, you typically would use `git rebase -i` or `git commit
--amend` to squash the fixes into the problematic patches. Thus, when
you re-submit the patches, they will appear to be "perfect".
For this particular two-patch series, patch [2/2] is doing two things:
(1) fixing style problems from patch [1/2], and (2) adding
documentation and tests which logically belong with the feature added
by patch [1/2]. Taking the above advice into account, a better
presentation when you re-submit this series would be to squash these
two patches into a single patch.
> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> ---
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> @@ -81,6 +82,9 @@ OPTIONS
> +--dedup::
> + Suppress duplicates entries when conflicts happen or
> + specify -d -m at the same time.
For consistency with typesetting elsewhere in this file, use backticks
around the command-line options. It also often is a good idea to spell
the options using long form since it is typically easier to search for
the long form of an option in documentation. So, perhaps the above can
be written like this:
Suppress duplicate entries when `--deleted` and `--modified` are
combined.
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> - const struct cache_entry *last_stage=NULL;
> + const struct cache_entry *last_stage = NULL;
> - if(show_cached && delete_dup){
> + if (show_cached && delete_dup) {
> - last_stage=ce;
> + last_stage = ce;
> - if(delete_dup){
> + if (delete_dup) {
> - if(delete_dup && show_deleted && show_modified && err)
> + if (delete_dup && show_deleted && show_modified && err)
> - else{
> - if (show_deleted && err)/* you can't find it,so it's actually removed at all! */
> + else {
> + if (show_deleted && err)
As mentioned above, these style fixes should be squashed into the
first patch, rather than being done in a separate patch, so that
reviewers see a nicely polished patch rather than a patch which
requires later fixing up.
> diff --git a/t/t3012-ls-files-dedup.sh b/t/t3012-ls-files-dedup.sh
> @@ -0,0 +1,63 @@
> +test_expect_success 'master branch setup and write expect1 expect2 and commit' '
We usually give this test a simple title such as "setup" so that we
don't have to worry about the title becoming outdated as people make
changes to the test itself.
> + touch a.txt &&
> + touch b.txt &&
> + touch delete.txt &&
On this project, we use `touch` when the timestamp of the empty files
is important to the test. If the timestamp is not important, then we
just use `>`, like this:
>a.txt &&
>b.txt &&
>delete.txt &&
> + cat <<-EOF >expect1 &&
> + M a.txt
> + H b.txt
> + H delete.txt
> + H expect1
> + H expect2
> + EOF
> + cat <<-EOF >expect2 &&
> + C a.txt
> + R delete.txt
> + EOF
When no variables are being interpolated in the here-doc content, we
use -\EOF to let readers know that the here-doc body is literal. So:
cat >expect1 <<-\EOF &&
...
EOF
> + git add a.txt b.txt delete.txt expect1 expect2 &&
> + git commit -m master:1
> +'
> +
> +test_expect_success 'main commit again' '
> + echo a>a.txt &&
> + echo b>b.txt &&
> + echo delete>delete.txt &&
> + git add a.txt b.txt delete.txt &&
> + git commit -m master:2
> +'
> +
> +test_expect_success 'dev commit' '
> + git checkout HEAD~ &&
> + git switch -c dev &&
> + echo change>a.txt &&
> + git add a.txt &&
> + git commit -m dev:1
> +'
These two tests following the "setup" test also seem to be doing setup
tasks rather than testing the new --dedup functionality. If this is
the case, then it probably would make sense to combine all three tests
into a single "setup" test.
> +test_expect_success 'dev merge master' '
> + test_must_fail git merge master &&
> + git ls-files -t --dedup >actual1 &&
> + test_cmp expect1 actual1 &&
> + rm delete.txt &&
> + git ls-files -d -m -t --dedup >actual2 &&
> + test_cmp expect2 actual2
> +'
Do you foresee that people will add more tests to this file which will
use the files and branches set up by the "setup" test(s)? If not, if
those branches and files are only ever going to be used by this one
test, then it probably would be better to combine all the above code
into a single test.
There was a problem hiding this comment.
On the Git mailing list, 胡哲宁 wrote (reply to this):
You can see that the coding and documentation of GIT community are really very
standard, which may be one of the things I lack and need to improve ;)
Thanks for patiently correct my errors.
Eric Sunshine <sunshine@sunshineco.com> 于2021年1月14日周四 下午2:39写道：
>
> On Fri, Jan 8, 2021 at 9:36 AM ZheNing Hu via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> > builtin:ls-files.c:add git ls-file --dedup option
>
> This subject concisely explains the purpose of the patch. That's good.
> A more typical way to write it would be:
>
> ls-files: add --dedup option
>
OK.I will correct it more specification.
> > This commit standardizes the code format.
>
> Fixing problems pointed out by reviewers is good. Normally, however,
> when you submit a new version of your patch or patch series, you
> should apply these fixes directly to the patch(es) which introduced
> the problems in the first place rather than adding one or more
> additional patches to fix problems introduced in earlier patches. To
> do this, you typically would use `git rebase -i` or `git commit
> --amend` to squash the fixes into the problematic patches. Thus, when
> you re-submit the patches, they will appear to be "perfect".
>
> For this particular two-patch series, patch [2/2] is doing two things:
> (1) fixing style problems from patch [1/2], and (2) adding
> documentation and tests which logically belong with the feature added
> by patch [1/2]. Taking the above advice into account, a better
> presentation when you re-submit this series would be to squash these
> two patches into a single patch.
>
I thought before this was gitgitgadget would sent duplicate patch
over and over again. It seems like I really should go straight ahead
and squash my commits , so I know what I should do.
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> > ---
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > @@ -81,6 +82,9 @@ OPTIONS
> > +--dedup::
> > + Suppress duplicates entries when conflicts happen or
> > + specify -d -m at the same time.
>
> For consistency with typesetting elsewhere in this file, use backticks
> around the command-line options. It also often is a good idea to spell
> the options using long form since it is typically easier to search for
> the long form of an option in documentation. So, perhaps the above can
> be written like this:
>
> Suppress duplicate entries when `--deleted` and `--modified` are
> combined.
>
> > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > - const struct cache_entry *last_stage=NULL;
> > + const struct cache_entry *last_stage = NULL;
> > - if(show_cached && delete_dup){
> > + if (show_cached && delete_dup) {
> > - last_stage=ce;
> > + last_stage = ce;
> > - if(delete_dup){
> > + if (delete_dup) {
> > - if(delete_dup && show_deleted && show_modified && err)
> > + if (delete_dup && show_deleted && show_modified && err)
> > - else{
> > - if (show_deleted && err)/* you can't find it,so it's actually removed at all! */
> > + else {
> > + if (show_deleted && err)
>
> As mentioned above, these style fixes should be squashed into the
> first patch, rather than being done in a separate patch, so that
> reviewers see a nicely polished patch rather than a patch which
> requires later fixing up.
>
> > diff --git a/t/t3012-ls-files-dedup.sh b/t/t3012-ls-files-dedup.sh
> > @@ -0,0 +1,63 @@
> > +test_expect_success 'master branch setup and write expect1 expect2 and commit' '
>
> We usually give this test a simple title such as "setup" so that we
> don't have to worry about the title becoming outdated as people make
> changes to the test itself.
>
> > + touch a.txt &&
> > + touch b.txt &&
> > + touch delete.txt &&
>
> On this project, we use `touch` when the timestamp of the empty files
> is important to the test. If the timestamp is not important, then we
> just use `>`, like this:
>
> >a.txt &&
> >b.txt &&
> >delete.txt &&
>
OK,maybe because I always use touch to generate files.
> > + cat <<-EOF >expect1 &&
> > + M a.txt
> > + H b.txt
> > + H delete.txt
> > + H expect1
> > + H expect2
> > + EOF
> > + cat <<-EOF >expect2 &&
> > + C a.txt
> > + R delete.txt
> > + EOF
>
> When no variables are being interpolated in the here-doc content, we
> use -\EOF to let readers know that the here-doc body is literal. So:
>
> cat >expect1 <<-\EOF &&
> ...
> EOF
>
> > + git add a.txt b.txt delete.txt expect1 expect2 &&
> > + git commit -m master:1
> > +'
> > +
> > +test_expect_success 'main commit again' '
> > + echo a>a.txt &&
> > + echo b>b.txt &&
> > + echo delete>delete.txt &&
> > + git add a.txt b.txt delete.txt &&
> > + git commit -m master:2
> > +'
> > +
> > +test_expect_success 'dev commit' '
> > + git checkout HEAD~ &&
> > + git switch -c dev &&
> > + echo change>a.txt &&
> > + git add a.txt &&
> > + git commit -m dev:1
> > +'
>
> These two tests following the "setup" test also seem to be doing setup
> tasks rather than testing the new --dedup functionality. If this is
> the case, then it probably would make sense to combine all three tests
> into a single "setup" test.
>
> > +test_expect_success 'dev merge master' '
> > + test_must_fail git merge master &&
> > + git ls-files -t --dedup >actual1 &&
> > + test_cmp expect1 actual1 &&
> > + rm delete.txt &&
> > + git ls-files -d -m -t --dedup >actual2 &&
> > + test_cmp expect2 actual2
> > +'
>
> Do you foresee that people will add more tests to this file which will
> use the files and branches set up by the "setup" test(s)? If not, if
> those branches and files are only ever going to be used by this one
> test, then it probably would be better to combine all the above code
> into a single test.
No,the test file may just need only one.
|
User |
adlternative
force-pushed
the
ls-files-dedup
branch
from
a09a509
to
5ce52c8
Compare
|
/preview |
|
Error: Could not determine public email of adlternative |
|
/preview |
|
Error: Could not determine public email of adlternative |
|
/submit |
|
Submitted as pull.832.v3.git.1610626942677.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): |
adlternative
force-pushed
the
ls-files-dedup
branch
from
5ce52c8
to
0c7830d
Compare
|
On the Git mailing list, 胡哲宁 wrote (reply to this): |
|
/preview |
|
On the Git mailing list, 胡哲宁 wrote (reply to this): |
|
Error: Could not determine public email of adlternative |
|
/submit |
|
Submitted as pull.832.v4.git.1610856136.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
| @@ -13,6 +13,7 @@ SYNOPSIS | |||
| (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Additional instructions:
> In order to display entries information,`deduplicate` suppresses
> the output of duplicate file names, not the output of duplicate
> entries information, so under the option of `-t`, `--stage`, `--unmerge`,
> `--deduplicate` will have no effect.
That information belongs to the end-user documentation.
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
This patch series was integrated into seen via git@357dc61. |
This situation may occur in the original code: lstat() failed but we use `&st` to feed ie_modified() later. Therefore, we can directly execute show_ce without the judgment of ie_modified() when lstat() has failed. Signed-off-by: ZheNing Hu <adlternative@gmail.com> [jc: fixed misindented code] Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will make it easier to show only one entry per filename in the next step. Signed-off-by: ZheNing Hu <adlternative@gmail.com> [jc: corrected the log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
During a merge conflict, the name of a file may appear multiple times in "git ls-files" output, once for each stage. If you use both `--delete` and `--modify` at the same time, the output may mention a deleted file twice. When none of the '-t', '-u', or '-s' options is in use, these duplicate entries do not add much value to the output. Introduce a new '--deduplicate' option to suppress them. Signed-off-by: ZheNing Hu <adlternative@gmail.com> [jc: extended doc and rewritten commit log] Signed-off-by: Junio C Hamano <gitster@pobox.com>
adlternative
force-pushed
the
ls-files-dedup
branch
from
07b603f
to
384f77a
Compare
|
/submit |
|
Submitted as pull.832.v7.git.1611485667.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
builtin/ls-files.c
Outdated
| @@ -335,7 +335,7 @@ static void show_files(struct repository *repo, struct dir_struct *dir) | |||
| for (i = 0; i < repo->index->cache_nr; i++) { | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: ZheNing Hu <adlternative@gmail.com>
>
> This situation may occur in the original code: lstat() failed
> but we use `&st` to feed ie_modified() later.
>
> Therefore, we can directly execute show_ce without the judgment of
> ie_modified() when lstat() has failed.
>
> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> [jc: fixed misindented code]
I noticed that you reverted my fix in this version, when this is
compared with the one I sent last night.
Comparing the result of applying all three with what I sent last
night, this v7 looks worse (see below). Let's discard this round
and declare victory with what is already on 'seen'.
Thanks.
---
comparison between what these three patches would produce (preimage)
and what is on 'seen' (postimage)is shown here.
diff --git w/builtin/ls-files.c c/builtin/ls-files.c
index fb9cf50d76..f6f9e483b2 100644
--- w/builtin/ls-files.c
+++ c/builtin/ls-files.c
@@ -313,7 +313,8 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
if (show_killed)
show_killed_files(repo->index, dir);
}
- if (! (show_cached || show_stage || show_deleted || show_modified))
+
+ if (!(show_cached || show_stage || show_deleted || show_modified))
return;
for (i = 0; i < repo->index->cache_nr; i++) {
const struct cache_entry *ce = repo->index->cache[i];
@@ -328,15 +329,16 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
if (ce->ce_flags & CE_UPDATE)
continue;
if ((show_cached || show_stage) &&
- (!show_unmerged || ce_stage(ce))) {
- show_ce(repo, dir, ce, fullname.buf,
- ce_stage(ce) ? tag_unmerged :
- (ce_skip_worktree(ce) ? tag_skip_worktree :
- tag_cached));
+ (!show_unmerged || ce_stage(ce))) {
+ show_ce(repo, dir, ce, fullname.buf,
+ ce_stage(ce) ? tag_unmerged :
+ (ce_skip_worktree(ce) ? tag_skip_worktree :
+ tag_cached));
if (skipping_duplicates)
goto skip_to_next_name;
}
- if (!show_deleted && !show_modified)
+
+ if (!(show_deleted || show_modified))
continue;
if (ce_skip_worktree(ce))
continue;
@@ -349,12 +351,13 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
goto skip_to_next_name;
}
if (show_modified &&
- (stat_err || ie_modified(repo->index, ce, &st, 0))) {
- show_ce(repo, dir, ce, fullname.buf, tag_modified);
+ (stat_err || ie_modified(repo->index, ce, &st, 0))) {
+ show_ce(repo, dir, ce, fullname.buf, tag_modified);
if (skipping_duplicates)
goto skip_to_next_name;
}
continue;
+
skip_to_next_name:
{
int j;
@@ -362,7 +365,7 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
for (j = i + 1; j < repo->index->cache_nr; j++)
if (strcmp(ce->name, cache[j]->name))
break;
- i = j - 1; /* compensate for outer for loop */
+ i = j - 1; /* compensate for the for loop */
}
}
@@ -590,7 +593,8 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
N_("pretend that paths removed since <tree-ish> are still present")),
OPT__ABBREV(&abbrev),
OPT_BOOL(0, "debug", &debug_mode, N_("show debugging data")),
- OPT_BOOL(0,"deduplicate",&skipping_duplicates,N_("suppress duplicate entries")),
+ OPT_BOOL(0, "deduplicate", &skipping_duplicates,
+ N_("suppress duplicate entries")),
OPT_END()
};
There was a problem hiding this comment.
On the Git mailing list, 胡哲宁 wrote (reply to this):
OK,I didn’t notice any formatting changes before.
Am I free from this patch now?I should probably
look for other issues.
Junio, thank you for all your patient help.
I may often make some low-level mistakes.
I am grateful.
Cheers.
Junio C Hamano <gitster@pobox.com> 于2021年1月25日周一 上午6:04写道：
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > This situation may occur in the original code: lstat() failed
> > but we use `&st` to feed ie_modified() later.
> >
> > Therefore, we can directly execute show_ce without the judgment of
> > ie_modified() when lstat() has failed.
> >
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> > [jc: fixed misindented code]
>
> I noticed that you reverted my fix in this version, when this is
> compared with the one I sent last night.
>
> Comparing the result of applying all three with what I sent last
> night, this v7 looks worse (see below). Let's discard this round
> and declare victory with what is already on 'seen'.
>
> Thanks.
>
>
> ---
>
> comparison between what these three patches would produce (preimage)
> and what is on 'seen' (postimage)is shown here.
>
> diff --git w/builtin/ls-files.c c/builtin/ls-files.c
> index fb9cf50d76..f6f9e483b2 100644
> --- w/builtin/ls-files.c
> +++ c/builtin/ls-files.c
> @@ -313,7 +313,8 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
> if (show_killed)
> show_killed_files(repo->index, dir);
> }
> - if (! (show_cached || show_stage || show_deleted || show_modified))
> +
> + if (!(show_cached || show_stage || show_deleted || show_modified))
> return;
> for (i = 0; i < repo->index->cache_nr; i++) {
> const struct cache_entry *ce = repo->index->cache[i];
> @@ -328,15 +329,16 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
> if (ce->ce_flags & CE_UPDATE)
> continue;
> if ((show_cached || show_stage) &&
> - (!show_unmerged || ce_stage(ce))) {
> - show_ce(repo, dir, ce, fullname.buf,
> - ce_stage(ce) ? tag_unmerged :
> - (ce_skip_worktree(ce) ? tag_skip_worktree :
> - tag_cached));
> + (!show_unmerged || ce_stage(ce))) {
> + show_ce(repo, dir, ce, fullname.buf,
> + ce_stage(ce) ? tag_unmerged :
> + (ce_skip_worktree(ce) ? tag_skip_worktree :
> + tag_cached));
> if (skipping_duplicates)
> goto skip_to_next_name;
> }
> - if (!show_deleted && !show_modified)
> +
> + if (!(show_deleted || show_modified))
> continue;
> if (ce_skip_worktree(ce))
> continue;
> @@ -349,12 +351,13 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
> goto skip_to_next_name;
> }
> if (show_modified &&
> - (stat_err || ie_modified(repo->index, ce, &st, 0))) {
> - show_ce(repo, dir, ce, fullname.buf, tag_modified);
> + (stat_err || ie_modified(repo->index, ce, &st, 0))) {
> + show_ce(repo, dir, ce, fullname.buf, tag_modified);
> if (skipping_duplicates)
> goto skip_to_next_name;
> }
> continue;
> +
> skip_to_next_name:
> {
> int j;
> @@ -362,7 +365,7 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
> for (j = i + 1; j < repo->index->cache_nr; j++)
> if (strcmp(ce->name, cache[j]->name))
> break;
> - i = j - 1; /* compensate for outer for loop */
> + i = j - 1; /* compensate for the for loop */
> }
> }
>
> @@ -590,7 +593,8 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
> N_("pretend that paths removed since <tree-ish> are still present")),
> OPT__ABBREV(&abbrev),
> OPT_BOOL(0, "debug", &debug_mode, N_("show debugging data")),
> - OPT_BOOL(0,"deduplicate",&skipping_duplicates,N_("suppress duplicate entries")),
> + OPT_BOOL(0, "deduplicate", &skipping_duplicates,
> + N_("suppress duplicate entries")),
> OPT_END()
> };
>
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
胡哲宁 <adlternative@gmail.com> writes:
> OK,I didn’t notice any formatting changes before.
>
> Am I free from this patch now?I should probably
> look for other issues.
I think we are pretty much done with it. Thanks for working on the
topic so patiently.
|
This patch series was integrated into seen via git@4583798. |
|
This patch series was integrated into seen via git@f0a190e. |
|
This patch series was integrated into seen via git@9b23fd9. |
|
This patch series was integrated into seen via git@7df4964. |
|
This patch series was integrated into seen via git@bcff65d. |
|
This patch series was integrated into next via git@af7522d. |
|
This patch series was integrated into seen via git@ce0049b. |
|
This patch series was integrated into seen via git@da779c9. |
|
This patch series was integrated into seen via git@af7522d. |
|
This patch series was integrated into seen via git@73de2fa. |
|
This patch series was integrated into seen via git@efd12f4. |
|
This patch series was integrated into seen via git@5198426. |
|
This patch series was integrated into next via git@5198426. |
|
This patch series was integrated into master via git@5198426. |
|
Closed via 5198426. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am reading the source code of git ls-files and learned
that git ls-files may have duplicate files name when there
are unmerged path in a branch merge or when different options
are used at the same time. Users may fell confuse when
they see these duplicate file names.
As Junio C Hamano said ,it have odd behaviour.
Therefore, we can provide an additional option to git ls-files to
delete those repeated information.
This fixes #198
Thanks!
cc: Eric Sunshine sunshine@sunshineco.com
cc: 胡哲宁 adlternative@gmail.com
cc: Junio C Hamano gitster@pobox.com
cc: Johannes Schindelin Johannes.Schindelin@gmx.de