git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stan Hu <stanhu@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3] sha1-name.c: Fix handling of revisions that contain paths with brackets
Date: Wed, 02 Jan 2019 12:35:50 -0800	[thread overview]
Message-ID: <xmqqftuakdax.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20181229054357.11716-1-stanhu@gmail.com> (Stan Hu's message of "Fri, 28 Dec 2018 21:43:58 -0800")

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? 

>  
> -	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.

      reply	other threads:[~2019-01-02 20:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-23 23:27 [PATCH] " Stan Hu
2018-12-23 23:37 ` Stan Hu
2018-12-23 23:40   ` [PATCH v2] " Stan Hu
2018-12-24  8:06     ` Duy Nguyen
2018-12-28 19:59       ` Junio C Hamano
2018-12-29  5:43       ` [PATCH v3] " Stan Hu
2019-01-02 20:35         ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqftuakdax.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=stanhu@gmail.com \
    --subject='Re: [PATCH v3] sha1-name.c: Fix handling of revisions that contain paths with brackets' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git