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

From: Anders Melchiorsen <mail@cup.kalibalik.dk>
Date: Nov 16, 2008, 09:00 UTC
Message-ID: <58634.N1gUGH5fRhE=.1226826015.squirrel@webmail.hotelhot.dk>
In-Reply-To: <7vr65c3xn5.fsf@gitster.siamese.dyndns.org>

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.