Junio C Hamano <gitster@xxxxxxxxx> writes:
> Martin Langhoff <martin.langhoff@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html