summaryrefslogtreecommitdiff
path: root/t/t3204-branch-name-interpretation.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-03-02checkout: restrict @-expansions when finding branchLibravatar Jeff King1-0/+10
When we parse "git checkout $NAME", we try to interpret $NAME as a local branch-name. If it is, then we point HEAD to that branch. Otherwise, we detach the HEAD at whatever commit $NAME points to. We do the interpretation by calling strbuf_branchname(), and then blindly sticking "refs/heads/" on the front. This leads to nonsense results when expansions like "@{upstream}" or "@" point to something besides a local branch. We end up with a local branch name like "refs/heads/origin/master" or "refs/heads/HEAD". Normally this has no user-visible effect because those branches don't exist, and so we fallback to feeding the result to get_sha1(), which resolves them correctly. But as the new test in t3204 shows, there are corner cases where the effect is observable, and we check out the wrong local branch rather than detaching to the correct one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02strbuf_check_ref_format(): expand only local branchesLibravatar Jeff King1-2/+2
This function asks strbuf_branchname() to expand any @-marks in the branchname, and then we blindly stick refs/heads/ in front of the result. This is obviously nonsense if the expansion is "HEAD" or a ref in refs/remotes/. The most obvious end-user effect is that creating or renaming a branch with an expansion may have confusing results (e.g., creating refs/heads/origin/master from "@{upstream}" when the operation should be disallowed). We can fix this by telling strbuf_branchname() that we are only interested in local expansions. Any unexpanded bits are then fed to check_ref_format(), which either disallows them (in the case of "@{upstream}") or lets them through ("refs/heads/@" is technically valid, if a bit silly). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02branch: restrict @-expansions when deletingLibravatar Jeff King1-3/+3
We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We can fix this by passing the appropriate "allowed" flag to strbuf_branchname(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02t3204: test git-branch @-expansion corner casesLibravatar Jeff King1-0/+123
git-branch feeds the branch names from the command line to strbuf_branchname(), but we do not yet tell that function which kinds of expansions should be allowed. Let's create a set of tests that cover both the allowed and disallowed cases. That shows off some breakages where we currently create or delete the wrong ref (and will make sure that we do not break any cases that _should_ be working when we do add more restrictions). Note that we check branch creation and deletion, but do not bother with renames. Those follow the same code path as creation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>