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

[Junio C Hamano <gitster@pobox.com>]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.