On Fri, 6 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
>
> > In order to do anything more capable with refspecs, the first step is
> > to keep the entire input. Additionally, validate patterns by checking
> > for the ref matching the rules for a pattern as given by
> > check_ref_format(). This requires a slight change to make it require
> > the '*' to be at the beginning of a path component.
>
> I had a brief "Huh?" moment wondering about this "slight change", but at
> this stage it does not change the rule at all ("/*" still must happen at
> the end of the string), so there actually is no change.
Ah, yes. A slight change to the code in refs.c to enforce the rule that
was enforced previously in remote.c.
> > diff --git a/remote.c b/remote.c
> > index 93fd03d..d0ce4c6 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -722,10 +716,10 @@ int remote_has_url(struct remote *remote, const char *url)
> > static int name_fits_pattern(const char *key, const char *name,
> > const char *value, char **result)
> > {
> > - size_t klen = strlen(key);
> > - int ret = !strncmp(key, name, klen);
> > + size_t klen = strchr(key, '*') - key;
> > + int ret = !strncmp(name, key, klen);
>
> Any particular reason why the first parameters to strncmp() were swapped?
An artifact of how I cleaned up the series that I didn't notice; I
originally wrote it from scratch with strncmp, with an arbitrary argument
order. Then I split out 2/5 using prefixcmp, and 3/5 keeping prefixcmp's
order, and didn't notice I didn't need the line of diff. So not really.
> > if (ret && value) {
> > - size_t vlen = strlen(value);
> > + size_t vlen = strchr(value, '*') - value;
>
> We would want protection from programming error here, to catch keys and
> values without any asterisk. This comment also applies to [5/5].
Good idea.
> > *result = xmalloc(vlen +
> > strlen(name) -
> > klen + 1);
>
-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
