Re: [PATCH 2/2] Add revision range support on "-" and "@{-1}"

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

Junio C Hamano <gitster@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.