SZEDER GGGbor <szeder@xxxxxxxxxx> wrote:
> Therefore, we introduce a new for-each-ref format called 'refbasename',
> which strips everything before and including the second '/' in the ref's
> name from the output.
>
> I assumed that refs always look like 'refs/{heads,tags,whatever}/foo',
> hence this patch breaks if a ref might look like 'refs/foo' or just
> 'foo'. But can I really rely on that?
>
> diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> index 21e92bb..1993ff4 100644
> --- a/builtin-for-each-ref.c
> +++ b/builtin-for-each-ref.c
> @@ -577,6 +578,10 @@ static void populate_value(struct refinfo *ref)
> char *s = xmalloc(len + 4);
> sprintf(s, "%s^{}", ref->refname);
> v->s = s;
> + } else if (!strcmp(name, "refbasename")) {
> + char * p = strchr(ref->refname, '/');
> + p = strchr(p+1, '/');
> + v->s = p+1;
Please be careful here and check for !p. A refname may be missing
one or two '/' in which case you will cause the process to segfault.
I don't think its a good idea to assume you'll always have to '/'
in the name. "refs/foo" can be created by git-update-ref. Or if
we ever started to report on HEAD this output tag would crash.
Also, as a style nit, its "p + 1" not "p+1".
Test cases?
On the other hand, I like where this is going. Given that it
has such a nice effect on the bash completion for larger repos
I'd like to see it in Git.
--
Shawn.
--
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
