Junio C Hamano <gits...@pobox.com> writes:

>> @@ -1499,6 +1500,13 @@ int handle_revision_arg(const char *arg_, struct 
>> rev_info *revs, int flags, unsi
>>                      next = head_by_default;
>>              if (dotdot == arg)
>>                      this = head_by_default;
>> +            /*  Allows -..<rev> and <rev>..- */
>> +            if (!strcmp(this, "-")) {
>> +                    this = prev_rev;
>> +            }
>> +            if (!strcmp(next, "-")) {
>> +                    next = prev_rev;
>> +            }
>
> The above two hunks are disappointing.  "this" and "next" are passed
> to get_sha1_committish() and the point of the [1/2] patch was to
> allow "-" to be just as usable as "@{-1}" anywhere a branch name can
> be used.
>
>>              if (this == head_by_default && next == head_by_default &&
>>                  !symmetric) {
>>                      /*
>> @@ -2198,7 +2206,7 @@ int setup_revisions(int argc, const char **argv, 
>> struct rev_info *revs, struct s
>>      read_from_stdin = 0;
>>      for (left = i = 1; i < argc; i++) {
>>              const char *arg = argv[i];
>> -            if (arg[0] == '-' && arg[1]) {
>> +            if (arg[0] == '-' && !strstr(arg, "..")) {
>
> Isn't this way too loose?  "--some-opt=I.wish..." would have ".."
> in it, and we would want to leave room to add new options that may
> take arbitrary string as an argument.
>
> I would have expected it would be more like
>
>               if (arg[0] == '-' && arg[1] && !starts_with(arg + 1, "..")) {
>
> That is, "anything that begins with '-', if it is to be taken as an
> option, must not begin with '-..'", which I think should be strict
> enough.

I have an updated version to handle the simplest forms of range
notations on 'pu' as d40f108d ("-" and "@{-1}" on various programs,
2015-03-16).  I do not think either your !strstr(arg, "..") or my
!starts_with(arg + 1, "..")  is correct, if we really wanted to make
"-" a true stand-in for @{-1}, as we would need to stop ourselves
fall into this "This begins with a dash, so it has to be a dashed
option" block when things like these are given:

    "-^"
    "-~10"
    "-^{/^### match next}"

I have a suspicion that it might be a matter of swapping the if
clauses, that is, instead of the current way

        if (starts with '-') {
                do the option thing;
                continue;
        }
        if (try to see if it is a revision or revision range) {
                /* if failed, args must be pathspecs from here on */
                check the '--' disambiguation;
                add pathspec to prune-data;
        } else {
                got_rev_arg = 1;
        }

which tries "the option thing" first, do something like this:

        if (try to see if it is a revision or regvision range) {
                /* if failed ... */
                if (starts with '-') {
                        do the option thing;
                        continue;
                }
                /* args must be pathspecs from here on */
                check the  '--' disambiguation;
                add pathspec to prune-data;
        } else {
                got_rev_arg = 1;
        }

but I didn't trace the logic myself to see if that would work.
--
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

Reply via email to