diff options
author | Jeff King <peff@peff.net> | 2017-03-02 03:23:01 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-03-02 11:05:04 -0800 |
commit | 0e9f62dab9fcce57279751bba47718d3f8baf3c8 (patch) | |
tree | f608d9f021ea84e09b0f24c3682891deacee33b0 /builtin/branch.c | |
parent | 0705fe202dd30009e2033e96a17cb12299bf5ab3 (diff) | |
download | git-0e9f62dab9fcce57279751bba47718d3f8baf3c8.tar.gz |
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/branch.c')
-rw-r--r-- | builtin/branch.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/builtin/branch.c b/builtin/branch.c index 475707528a..5aab33ab58 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -215,7 +215,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds, char *target = NULL; int flags = 0; - strbuf_branchname(&bname, argv[i]); + strbuf_branchname(&bname, argv[i], 0); free(name); name = mkpathdup(fmt, bname.buf); |