On Mon, Aug 26, 2013 at 05:03:04PM -0400, Phil Hord wrote: > > $ 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.
I certainly assumed it was, because it is in most cases it is. And something like "HEAD:RelNotes/22.214.171.124.txt" certainly _looks_ like one, and is generated by the current git. And what is the point of coming up with a file listing if the names you return do not actually exist? > 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). Yes, though we seem to normalize paths already. So the other entries from that command are (in git.git): HEAD:../.mailmap HEAD:RelNotes/126.96.36.199.txt So we could either: 1. Prepend the current path before normalizing to yield: HEAD:.mailmap HEAD:Documentation/RelNotes/188.8.131.52.txt 2. Teach the get_sha1 path parser about "..", and prepend "./" when we are in a prefixed subdir. HEAD:./../.mailmap HEAD:./RelNotes/184.108.40.206.txt -Peff -- 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