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

"Anders Melchiorsen" [off-list ref] writes:

Junio C Hamano wrote:

quoted

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

Junio C Hamano wrote:

"Anders Melchiorsen" [off-list ref] writes:

quoted

Junio C Hamano wrote:

quoted

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.