Re: [PATCH 1/2] Adding - shorthand for @{-1} in RESET command

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

Eric Sunshine <sunshine@sunshineco.com> writes:

>> @@ -226,7 +233,14 @@ static void parse_args(struct pathspec *pathspec,
>>                         rev = *argv++;
>>                 } else {
>>                         /* Otherwise we treat this as a filename */
>> -                       verify_filename(prefix, argv[0], 1);
>> +                       if(file_named_minus) {
>> +                               die(_("ambiguous argument '-': both revision and filename\n"
>> +                                       "Use ./- for file named -\n"
>> +                                       "Use '--' to separate paths from revisions, like this:\n"
>> +                                       "'git <command> [<revision>...] -- [<file>...]'"));
>
> This seems odd. If arguments following '--' are unconditionally
> treated as paths, why is it be necessary to tell the user to spell out
> file '-' as './-'? Shouldn't "git reset -- -" be sufficient?

I find that the presense of the if statement itself even odder.

 - verify_filename() and verify_non_filename() are designed to check
   that the string "-" given by the end-user is or is not a filename
   on the filesystem.  Why isn't this caller letting the callee do
   the job it was designed to do and doing that itself instead?

 - we know "-" aka "@{-1}" does not resolve to a committish at this
   point, so it must be a filename.  If "-" exists, then why should
   the user even need to differenciate it as ./- (or with "-- -")?

   After all, if there is no branch whose name is 'foo' and a file
   'foo' exists on the filesystem, the user can say "git reset foo"
   without disambiguation to reset that path, no?