Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
> Tries to shorten the refname to a non-ambiguous name.
> I.e. the full and the short refname points to the same object.
The definition of "ambiguity" here is wrong (see below).
> + /* skip first rule, will always match */
> + for (i = 0; i < nr_rules - 1; i++) {
> + const char **p;
> + int short_name_len;
> +
> + if (1 != sscanf(ref->refname, scanf_fmts[nr_rules - 1 - i],
> + short_name))
> + continue;
> +
> + short_name_len = strlen(short_name);
> +
> + /* check if full and short point to the same object
Style?
> + * by checking all rules in forward direction
> + */
I think this part of the code is wrong, in that it talks about what object
the ref points at. That is not what ref ambiguity is about.
Given a tag that points at a version 1.0.0 commit, this sequence will
create:
$ git tag foo v1.0.0^0
$ git branch foo v1.0.0^0
ambiguous branch and tag whose names are both 'foo', even though they
point at the same thing. The right API to use would be resolve_ref(), I
think.
Other than that, it is well done.
Although I was initially a bit surprised by the size of the patch to
implement something so (conceptually) simple, the code was easy and
straightforward to follow.
Thanks.
--
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
