git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] make sure parsed wildcard refspec ends with slash
Date: Sun, 27 Jul 2008 13:20:34 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LNX.1.00.0807271257400.19665@iabervon.org> (raw)
In-Reply-To: <7vsktv3l9k.fsf_-_@gitster.siamese.dyndns.org>

On Sat, 26 Jul 2008, Junio C Hamano wrote:

> A wildcard refspec is internally parsed into a refspec structure with src
> and dst strings.  Many parts of the code assumed that these do not include
> the trailing "/*" when matching the wildcard pattern with an actual ref we
> see at the remote.  What this meant was that we needed to make sure not
> just that the prefix matched, and also that a slash followed the part that
> matched.
> 
> But a codepath that scans the result from ls-remote and finds matching
> refs forgot to check the "matching part must be followed by a slash" rule.
> This resulted in "refs/heads/b1" from the remote side to mistakenly match
> the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.
> 
> Worse, the refspec crafted internally by "git-clone", and a hardcoded
> preparsed refspec that is used to implement "git-fetch --tags", violated
> this "parsed widcard refspec does not end with slash" rule; simply adding
> the "matching part must be followed by a slash" rule then would have
> broken codepaths that use these refspecs.
> 
> This commit changes the rule to require a trailing slash to parsed
> wildcard refspecs.  IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as
> src = "refs/heads/b/" and dst = "refs/remotes/b/".  This allows us to
> simplify the matching logic because we only need to do a prefixcmp() to
> notice "refs/heads/b/one" matches and "refs/heads/b1" does not.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I have a nagging suspicion that it might be a simpler and cleaner change
> > to change parse_refspec_internal() to keep the trailing slash, instead of
> > dropping it.  Then the check you added is not needed (the trailing slash
> > guarantees that the pattern matches at the hierarchy boundary), neither
> > any of the change in this patch.
> 
> This is the other variant, and it turns out that I was right.  Among the
> 64-18 = 46 new lines, 30 are from the new test file.  Two existing
> "matching part is followed by '/'" tests are removed.

Yeah, the first version of this code included the '/', by virtue of having 
the '/' not be required in the refspec (i.e., you could have 
"refs/heads/b*"); when you told me that refspecs needed to have a '/' 
before the '*', I thought that it would be easiest to not include the '/', 
since it was redundant, but, in retrospect, I'm not too surprised that it 
simplifies things to include it.

Acked-by: Daniel Barkalow <barkalow@iabervon.org>

>  remote.c               |   52 +++++++++++++++++++++++++++++++----------------
>  t/t5513-fetch-track.sh |   30 +++++++++++++++++++++++++++
>  2 files changed, 64 insertions(+), 18 deletions(-)
> 
> diff --git a/remote.c b/remote.c
> index 0d6020b..f61a3ab 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -427,6 +427,28 @@ static void read_config(void)
>  	alias_all_urls();
>  }
>  
> +/*
> + * We need to make sure the tracking branches are well formed, but a
> + * wildcard refspec in "struct refspec" must have a trailing slash. We
> + * temporarily drop the trailing '/' while calling check_ref_format(),
> + * and put it back.  The caller knows that a CHECK_REF_FORMAT_ONELEVEL
> + * error return is Ok for a wildcard refspec.
> + */
> +static int verify_refname(char *name, int is_glob)
> +{
> +	int result, len = -1;
> +
> +	if (is_glob) {
> +		len = strlen(name);
> +		assert(name[len - 1] == '/');
> +		name[len - 1] = '\0';
> +	}
> +	result = check_ref_format(name);
> +	if (is_glob)
> +		name[len - 1] = '/';
> +	return result;
> +}
> +

Maybe check_ref_format() ought to have a return for "this is valid as a 
directory rather than a single ref", and that would be allowed with globs? 
I'm not too fond of temporarily changing strings for testing. Also, this 
design (while it matches the current code), means that check_ref_format() 
sees one fewer level than the refs that match will actually have, which is 
a little confusing.

	-Daniel
*This .sig left intentionally blank*

  reply	other threads:[~2008-07-27 17:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 23:13 [PATCH] bash completion: Add completion for 'git help' Lee Marlow
2008-07-24  0:07 ` Lee Marlow
2008-07-25 20:40   ` Shawn O. Pearce
2008-07-25 21:02     ` Junio C Hamano
2008-07-26  8:24       ` fetch refspec foo/* matches foo* Jeff King
2008-07-26  8:33         ` Jeff King
2008-07-26 13:13           ` [PATCH] init: handle empty "template" parameter, was " Johannes Schindelin
2008-07-28  6:02             ` Jeff King
2008-07-28  6:13               ` Junio C Hamano
2008-07-28  6:16                 ` Jeff King
2008-07-27  0:18         ` Junio C Hamano
2008-07-27  6:15           ` [PATCH] make sure parsed wildcard refspec ends with slash Junio C Hamano
2008-07-27 17:20             ` Daniel Barkalow [this message]
2008-07-28  5:41             ` Jeff King
2008-07-24  0:08 ` [PATCH] bash completion: Add completion for 'git help' Lee Marlow

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=alpine.LNX.1.00.0807271257400.19665@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).