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

2 messages from 2019-03-21 to 2019-03-22. Participants: Leszek Swirski, Junio C Hamano.
Thread: https://gitlist.dev/t/50795

## Leszek Swirski, 2019-03-21 15:43

Subject: Bug: git checkout @{u} breaks git branch if the upstream isn't a local branch
Message-ID: <CAGRskv__Qe-F-grBtq5v-uhHE+BQAcAcOQtX-GKB+MNOrxs0hQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAGRskv__Qe-F-grBtq5v-uhHE%2BBQAcAcOQtX-GKB%2BMNOrxs0hQ%40mail.gmail.com

```
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, 2019-03-22 05:02

Subject: Re: Bug: git checkout @{u} breaks git branch if the upstream isn't a local branch
Message-ID: <xmqq7ecrqz65.fsf@gitster-ct.c.googlers.com>
URL: https://gitlist.dev/e/xmqq7ecrqz65.fsf%40gitster-ct.c.googlers.com
In-Reply-To: <CAGRskv__Qe-F-grBtq5v-uhHE+BQAcAcOQtX-GKB+MNOrxs0hQ@mail.gmail.com>

```
Leszek Swirski <leszeks@google.com> writes:

> 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.


```