threads / bug / 50795

Bug: git checkout @{u} breaks git branch if the upstream isn't a local branch

Subject: Bug: git checkout @{u} breaks git branch if the upstream isn't a local branch

## tl;dr

2 messages between Mar 21, 2019 and Mar 22, 2019.

replies: 1people: 2as markdown or json

Leszek Swirski· Mar 21, 2019, 15:43 UTC · lore

Consider a repository with branch master, with upstream origin/master. If one is on master, and runs "git checkout @{u}" to get the upstream, then git branch stops working. The reason is that we end up on a detached HEAD, and git branch searches recent reflog entries to figure out where the HEAD was detached from (wt-status.c: wt_status_get_detached_from). Since @{u} is not a local branch, the checkout is inserted into the reflog as "moving from master to @{u}" rather than "moving from master to origin/master". This is because setup_branch_path (checkout.c) only updates the branch name for local branches, keeping the input name (here, "@{u}") otherwise. So, git branch sees "@{u}", decides that we are detached from "@{u}", tries to lookup "HEAD@{u}" and fails with "fatal: HEAD does not point to a branch"

I assume that either the reflog entry should be amended to print something more informative (moving from master to origin/master, or at least master@{u}, or the SHA...), or the reflog search in wt_status_get_detached_from should do something cleverer with relative refs.

- Leszek

Junio C Hamano· Mar 22, 2019, 05:02 UTC · re: Leszek Swirski · lore

Re: Bug: git checkout @{u} breaks git branch if the upstream isn't a local branch

Leszek Swirski <leszeks@google.com> writes:

Show 5 quoted lines

> I assume that either the reflog entry should be amended to print
> something more informative (moving from master to origin/master, or at
> least master@{u}, or the SHA...), or the reflog search in
> wt_status_get_detached_from should do something cleverer with relative
> refs.

Nicely analyzed. A record "moving to @{u}" in the reflog may not leave sufficient information for a later operation to tell what branch was refered to with the @{u} reference back when "checkout" was run. I suspect that checking out @{4}, @{1.day.ago}, etc. may share the same issue.

"git checkout @{-1}" aka "git checkout -" may not have any problem after such a checkout, as it only uses "moving from" side of the reflog entry.