On Mon, Aug 26, 2013 at 4:52 PM, Jeff King <p...@peff.net> wrote: > On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote: > >> Am 26.08.2013 21:56, schrieb Jeff King: >> > Also, prevent the delimiter being added twice, as happens now in these >> > examples: >> > >> > git grep -l foo HEAD: >> > HEAD::some/path/to/foo.txt >> > ^ >> >> Which one of these two does it print then? >> >> HEAD:/some/path/to/foo.txt >> HEAD:some/path/to/foo.txt > > It should (and does) print the latter. > > But I do note that our pathspec handling for subdirectories seems buggy. > If you do: > > $ cd Documentation > $ git grep -l foo | head -1 > RelNotes/184.108.40.206.txt > > that's fine; we limit to the current directory. But then if you do: > > $ git grep -l foo HEAD | head -1 > HEAD:RelNotes/220.127.116.11.txt > > we still limit to the current directory, but the output does not note > this (it should be "HEAD:./RelNotes/18.104.22.168.txt"). I think this bug is > orthogonal to Phil's patch, though.
Maybe not. My path completes the assumption that the L:R value returned by grep is an object ref; but Junio still thought it wasn't. I think this is another case where his view was correct. There's more bad news on this front. $ cd Documentation $ git grep -l foo HEAD .. | head -1 HEAD:../.gitignore That's not a valid ref, either (though maybe it could be). Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html