Re: [PATCH 2/4] add -u: get rid of "treewideupdate" configuration

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2011, 04:56 UTC
Message-ID: <7v39ls10q6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110409043824.GA22543@do>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 6 quoted lines

> 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.