Re: Relative ls-files

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 23, 2011, 17:35 UTC
Message-ID: <7vzkoleo45.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v7hbqgc7g.fsf@alter.siamese.dyndns.org>

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

Show 9 quoted lines

> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
>> and the answer is git ls-files --with-tree=<treeish> | grep <regex> .
>> But the --with-tree param is so counterintuitive to me that I read the
>> manpage, everytime.
>
> Because --with-tree nor ls-files is the tool that was designed for.
>
> If you want to find out about a branch, why aren't you using "ls-tree -r"?

It obviously needs a side note to answer "what is 'ls-files --with-tree' for, then?", so here is such a note.

The --with-tree option was invented for the sole purpose of helping "git commit -- $paths" back when "commit" was still a scripted Porcelain. We wanted to make sure that the $paths given from the command line made sense (we wanted to diagnose e.g. "git commit Mkaefile" as a typo).

The obvious plumbing to check if the given pathspec matches what are known to git (i.e. in the index) is:

	git ls-files --error-unmatch -- $paths

but there is a catch. If you are about to commit a removal of a path, i.e.

	$ rm -f generated-file.c
	$ git update-index --remove generated-file.c
        $ git commit -m "Do not keep a generated file in SCM" generated-file.c

the above ls-files would report that the pathspec "generated-file.c" does not match, as that path is no longer in the index.

To make the "ls-files --error-unmatch" useful for this check, we use:

	git ls-files --error-unmatch --with-tree=HEAD -- $paths

to overlay the contents of the tree on top of what is already in the index and then determine what paths are "known" to git at that point.

So your use of "git ls-files --with-tree=<unrelated branch>" has been giving results that you didn't want to see, as the set of paths in your index that is based on your current branch most likely are different from what is in that unrelated branch.

I don't think there is any in-tree users of --with-tree option anymore, other than the tests, so it probably is not even worth thinking about removing it and replacing it with a --with-head-tree (as using any commit other than HEAD makes little sense) option.