threads / bug / 16320

[BUG] git ls-files -m --with-tree does double output

Subject: [BUG] git ls-files -m --with-tree does double output

## tl;dr

6 messages between Nov 13, 2008 and Nov 16, 2008.

replies: 5people: 2as markdown or json

Anders Melchiorsen· Nov 13, 2008, 21:53 UTC · lore

Junio, I am resending this one because I am not sure whether you ignored it on purpose, or it got lost during your vacation.

The combination of -m and --with-tree shows duplicate entries:

and@dylle:~$ mkdir repo ; cd repo
and@dylle:~/repo$ git init
Initialized empty Git repository in /home/and/repo/.git/
and@dylle:~/repo$ date >a ; git add a ; git commit -m'Add 1'
Created initial commit c027435: Add 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
and@dylle:~/repo$ date >a
and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
a
a

Jeff King added:

I have confirmed this, and it looks like it has always been that way. It looks like overlay_tree_on_cache just does a read_tree to pull the tree into the index, and then we end up with duplicate entries.

I'm not too familiar with the read_tree code, so I am cc'ing Junio (who is out of touch for a little while) and Linus, who are much more clueful in this area.

It isn't clear to me which code is _supposed_ to be pulling out such duplicates here. That is, is read_tree broken, or is overlay_tree_on_cache just calling it wrong?

Anders.

Junio C Hamano· Nov 13, 2008, 22:35 UTC · re: Anders Melchiorsen · lore

Re: [BUG] git ls-files -m --with-tree does double output

"Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:

Show 10 quoted lines

> and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
> a
> a
>
>
> Jeff King added:
> ...
> It isn't clear to me which code is _supposed_ to be pulling out such
> duplicates here. That is, is read_tree broken, or is
> overlay_tree_on_cache just calling it wrong?

I had to look up what -m meant in ls-files, as I never considered that option as part of the plumbing.

What's the use case of using -m together with --with-tree to begin with? I think the only sensible other option that makes sense with --with-tree is --error-unmatch.

Junio C Hamano· Nov 13, 2008, 22:39 UTC · re: Junio C Hamano · lore

Re: [BUG] git ls-files -m --with-tree does double output

Junio C Hamano <gitster@pobox.com> writes:

> What's the use case of using -m together with --with-tree to begin with?
> I think the only sensible other option that makes sense with --with-tree
> is --error-unmatch.

The reason I ask this question is that the cleanest fix to the issue might turn out to be to forbid that combination of the options, if it turns out that it does not make any sense.

Anders Melchiorsen· Nov 13, 2008, 23:11 UTC · re: Junio C Hamano · lore

Re: [BUG] git ls-files -m --with-tree does double output

Junio C Hamano wrote:

> What's the use case of using -m together with --with-tree to begin with?

The script runs

   git ls-files -d -m -o -t --with-tree=HEAD

to get a parseable "git status"-like output. If I leave out --with-tree=HEAD, I do not get information about staged changes.

I could use "git diff --name-status HEAD", but then there was a problem about untracked files, I think.

Thanks, Anders.

Junio C Hamano· Nov 16, 2008, 08:03 UTC · re: Anders Melchiorsen · lore

Re: [BUG] git ls-files -m --with-tree does double output

"Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:

Show 10 quoted lines

> Junio C Hamano wrote:
>
>> What's the use case of using -m together with --with-tree to begin with?
>
> The script runs
>
>    git ls-files -d -m -o -t --with-tree=HEAD
>
> to get a parseable "git status"-like output. If I leave out
> --with-tree=HEAD, I do not get information about staged changes.

I think a machine parsable "status equivalent" is a good thing to have, but I do not think the internal machinery of ls-files is equipped to do that. Didn't I send "here is how you would do it" patch some time ago, so that interested parties can build on it to do that?

I lack the context to interpret what you mean by "The script", but in any case, the only use case --with-tree was designed for was to use it in conjunction with --error-unmatch inside the scripted version of "git commit", to see if the paths given by the users make sense as a request to create a partial commit. It is not entirely surprising if any other funny options do not work with it at all.

Having said all that, I think this would fix it.

 builtin-ls-files.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git c/builtin-ls-files.c i/builtin-ls-files.c
index b48327d..b28a185 100644
--- c/builtin-ls-files.c
+++ i/builtin-ls-files.c
@@ -227,6 +227,8 @@ static void show_files(struct dir_struct *dir, const char *prefix)
 			int dtype = ce_to_dtype(ce);
 			if (excluded(dir, ce->name, &dtype) != dir->show_ignored)
 				continue;
+			if (ce->ce_flags & CE_UPDATE)
+				continue;
 			err = lstat(ce->name, &st);
 			if (show_deleted && err)
 				show_ce_entry(tag_removed, ce);

Anders Melchiorsen· Nov 16, 2008, 09:00 UTC · re: Junio C Hamano · lore

Re: [BUG] git ls-files -m --with-tree does double output

Junio C Hamano wrote:

Show 14 quoted lines

> "Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:
>
>> Junio C Hamano wrote:
>>
>>> What's the use case of using -m together with --with-tree to begin
>>> with?
>>
>> The script runs
>>
>>    git ls-files -d -m -o -t --with-tree=HEAD
>>
>> to get a parseable "git status"-like output. If I leave out
>> --with-tree=HEAD, I do not get information about staged changes.
>

> [...]

Show 6 quoted lines

> I lack the context to interpret what you mean by "The script", but in any
> case, the only use case --with-tree was designed for was to use it in
> conjunction with --error-unmatch inside the scripted version of "git
> commit", to see if the paths given by the users make sense as a request to
> create a partial commit.  It is not entirely surprising if any other funny
> options do not work with it at all.

"The script" is just a random script I was writing when I found this issue.

If --with-tree is only meant for --error-unmatch, maybe update the help to show it like this,

    [--error-unmatch [--with-tree=<tree-ish>]]

I never read the description of --with-tree, I just found the parameter in the top of the man page and tried it out. It did what I wanted, but gave double output. And so I reported that in this thread, as I believed it to be an error.

Now I understand that I am using ls-files in unintended ways, but I cannot really fix that when no "git status" like plumbing tool is available.

> Having said all that, I think this would fix it.

That sure seems to fix my test case.

Anders.