Re: [PATCH v3] sha1-name.c: Fix handling of revisions that contain paths with brackets

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 2, 2019, 20:35 UTC
Message-ID: <xmqqftuakdax.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181229054357.11716-1-stanhu@gmail.com>

Stan Hu <stanhu@gmail.com> writes:

> -	if (len < 4 || name[len-1] != '}')
> +	if (len < 4)
>  		return -1;

The original does not expect any string given after the ^{<type>} dereferencer, like :<path>, and that is why this function returns very early for anything when name[len-1] is not a closing brace.

We do not do that anymore, because...?

This gives me a nagging feeling that the patch is barking up a wrong tree. Consider what happens when a path that does not have any funny characters, e.g. "v1.4.0^{tree}:a/b/c", is given from the top level of the request chain (e.g. "rev-parse v1.4.0^{tree}:a/b/c")? The caller must be feeding this function "v1.4.0^{tree}" after finding the colon before the path "a/b/c" and setting len to point at the colon---otherwise we won't be checking for "}" at the end like this.

When given "master^{tree}:a/b/{c}", wouldn't the caller be doing the same stripping to find the colon and calling this function with len pointing at the colon before the path (i.e. "master^{tree}")?

To put it another way, it is OK if this patch wants to shift the responsibility of finding the colon that separates the tree-ish part and the path part from the caller to this function, but then I would expect changes to the caller, because now the caller does not have to find ":a/b/c" in "v1.4.0^{tree}:a/b/c" and set up the len before calling this function. Why can the resulting code after applying this patch be correct without such a matching change?

Show 8 quoted lines

>  
> -	for (sp = name + len - 1; name <= sp; sp--) {
> +	for (sp = name; sp < name + len; sp++) {
>  		int ch = *sp;
> -		if (ch == '{' && name < sp && sp[-1] == '^')
> +		if (ch == '^' && sp < name + len && sp[1] == '{')
>  			break;
>  	}

We used to scan from the tail (as we expected that the caller gives us a (name, len) that ends with "^{<type>}". The updated code instead scans from the front, looking for "^{". I do not particularly mind the change of strategy, as long as it is correctly done, but I suspect the function will stay simpler if the callee is fixed instead.

The only troublesome case is the REV^{/...} syntax.  For example,

	HEAD^{/^Git 2.0}^{tree}:t/

would want to find the commit "HEAD^{/^Git 2.0}", peel it down to a tree object with "^{tree}" and then take its "t/" subtree. It used to be that the caller (get_oid_with_context_1() has a loop that finds a colon outside "{...}" and that finds ":t/" before calling get_oid_1()) was responsible to give us "HEAD^{/^Git 2.0}^{tree}" by stripping ":t/", and I presume that it is still happening, but the above loop would terminate upon seeing "^{" immediately after HEAD, without even realizing that it has ^{tree} after it.

> -	if (sp <= name)
> +
> +	if (sp == name + len)
>  		return -1;

> -	sp++; /* beginning of type name, or closing brace for empty */
> -	if (starts_with(sp, "commit}"))
> +	sp += 2; /* beginning of type name, or closing brace for empty */

And this comment indicates that the code did not expect to see ^{/^Git 2.0} before ^{tree}.

I do not quite follow.  How can this patch be correct?

Puzzled.

$ git rev-parse "master^{/^Git 2.0}^{tree}" bc6ce29d1ec757d9d036532531a1046db4da0d96 $ ./git rev-parse "master^{/^Git 2.0}^{tree}" master^{/^Git 2.0}^{tree} fatal: ambiguous argument 'master^{/^Git 2.0}^{tree}': unknown revision or path not in the working tree.