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

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

[Anders Melchiorsen]

I think that this is wrong? The combination of -m and --with-tree
shows duplicate entries. Git 1.6.0.2.


Cheers,
Anders.


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

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

[Jeff King]

On Wed, Sep 24, 2008 at 06:19:32PM +0200, Anders Melchiorsen wrote:

> I think that this is wrong? The combination of -m and --with-tree
> shows duplicate entries. Git 1.6.0.2.

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?

-Peff

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

[Anders Melchiorsen]

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.

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

[Junio C Hamano]

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

> 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.

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

[Junio C Hamano]

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.

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

[Anders Melchiorsen]

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.

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

[Junio C Hamano]

"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.

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

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

[Anders Melchiorsen]

Junio C Hamano wrote:
> "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.
>

> [...]

> 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.