2013-06-18 AM 12:53, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Wouldn't it make more sense to see if the given pattern matches a
tail substring of the ref, instead of using the hardcoded "strip
refs/heads/, refs/tags or refs/, and then match once" logic? That
way, --refs=origin/* can find refs/remotes/origin/master by running
fnmatch of origin/* against its substrings, i.e.
refs/remotes/origin/master
remotes/origin/master
origin/master
and find that the pattern matches it.
Perhaps it is just the matter of adding something like:
...
and then at the beginning of name_ref() do this:
int can_abbreviate_output = data->name_only;
if (data->tags_only && prefixcmp(path, "refs/tags/"))
return 0;
if (data->ref_filter) {
switch (subpath_matches(path, data->ref_filter)) {
case -1: /* did not match */
return 0;
default: /* matched subpath */
can_abbreviate_output = 1;
break;
case 0: /* matched fully */
break;
}
}
The logic before calling name_rev() will be kept as "only decide how
the output looks like", without mixing the unrelated "decide if we
want to use it" logic in.
... which may make the "call name_rev with this abbreviated path"
logic look something like this:
if (o && o->type == OBJ_COMMIT) {
if (can_abbreviate_output)
path = shorten_unambiguous_ref(path, 0);
else if (!prefixcmp(path, "refs/heads/"))
path = path + 11;
else if (data->tags_only
&& data->name_only
&& !prefixcmp(path, "refs/tags/"))
path = path + 10;
else if (!prefixcmp(path, "refs/"))
path = path + 5;
name_rev((struct commit *) o, xstrdup(path), 0, 0, deref);
}
Hmm.. I thought about it twice.
This will affects the output of `--name-only
--refs=refs/remotes/origin/*` case. (AFAIK it only affected to tags so
far) As the name_only always sets can_abbreviate_output, it'll shorten
the name of remote ref even if it's fully matched.
$ ./git name-rev --refs=refs/remotes/origin/* a2055c2
a2055c2 remotes/origin/maint~642
$ ./git name-rev --refs=refs/remotes/origin/* --name-only a2055c2
origin/maint~642
I think it should be 'data->tags_only && data->name_only' for
compatibility reason.
I also see that the 3rd condition of 'tags_only && name_only' turned out
to be useless for the similar reason. When name_only set, it'll take
the first case so 3rd case cannot be reached. When it's not set it
cannot take the third case too obviously. So I'll just remove it.
Thanks,
Namhyung
--
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