Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes:
> On Fri, Apr 08, 2011 at 04:18:46PM -0700, Junio C Hamano wrote:
>> It appears that we might want to further tweak the code that tries to
>> disambiguate between revs and paths (we error out when argv[i] does not
>> name a rev and lstat(argv[i]) fails)
>
> Something like below?
That's too loose for my taste. At that point in the codepath, don't we
sometimes expect the argv[i] might name a blob in the index?
By "we might want to further...", I meant "when we properly redesign the
get_pathspec vs init_pathspec combination".
There are places in the current code that call verify_filename() to make
sure that argv[i] is a pathspec after making sure argv[i] cannot be an
object name. Currently it just does lstat() on it to see if it names a
path.
Instead, when we refactor get/init-pathspec API, we could expose an
interface to turn one element from argv[] into a "struct pathspec_item".
Then we can try to feed argv[i] to that string-to-pathspec_item function,
and consider that argv[i] _is_ a proper pathspec only if it parses
correctly *and* if it matches either an item in the current working tree.
That would be a moral equivalent of the current verify_filename() check
but is far more precise one; e.g. the current code rejects
git grep -e foo '*.c' ;# bad
because '*.c' is not an object name, but lstat("*.c") fails, and you need
to disambiguate with '--'. If you rewrite the verify_filename() in the
way I outlined above, you wouldn't have to.
--
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