unable to checkout remote branch when existing local branch has the same name

ggrrll commented 6 years ago

Hi,

first of all, thanks for this nice tool.

I am getting this error message A branch with that name already exists. (as shown in the attchement) , when I click on Other branches , which are branches that do not appear anyway with git ls-remote – not sure if this is related to #2964

Thanks for your help.

ps: I am using v 1.1.1 on mac os 10.13.4

shiftkey commented 6 years ago

@ggrrll as mentioned in #3624, I think there's a corner case here that's tricky to fix:

https://github.com/desktop/desktop/blob/be2712877593641de83b7104da6569e113a2f033/app/test/unit/git/checkout-test.ts#L112

This test tries to checkout a remote branch where it has the same name as an existing local branch, and it currently fails. Can you confirm that's the same behaviour you're seeing:

you have a existing local branch named [something]
you're trying to checkout a remote branch named [something]

ggrrll commented 6 years ago

Thanks @shiftkey.

Not sure indeed of what's happening... :( I guess I messed up a bit in the past, as I tried to connect two other remote repos (actually from Overleaf), which I later tried to remove, to the same local directory.

They way I understand it is that those two 'other branches' are old remote repositories that actually still appear in git branch -a

shiftkey commented 6 years ago

Could you attach the full log files? The Help | Show Logs in Explorer menu items should open the logs folder, and inside those are the log files generated by day. This will provide some more information to help troubleshoot.

ggrrll commented 6 years ago

sure – this is the part of the error

2018-04-25T12:43:38.725Z - error: [ui] `git -c credential.helper= checkout --progress overleaf/master -b master --` exited with an unexpected code: 128.
fatal: A branch named 'master' already exists.

(The error was parsed as 25: A branch with that name already exists.)

iAmWillShepherd commented 6 years ago

@ggrrll could you attach the full logs?

ggrrll commented 6 years ago

ok sorry, here you go 2018-04-25.desktop.production.log

shiftkey commented 6 years ago

Yeah, there's repetitions of the same error in here:

2018-04-25T12:43:38.725Z - error: [ui] `git -c credential.helper= checkout --progress overleaf/master -b master --` exited with an unexpected code: 128.
fatal: A branch named 'master' already exists.

I gather that the existing master is tracking origin/master or something similar.

A potential solution for this would be to, in cases where an existing local branch exists and will clash, use the convention {remote}-{branch} when the user wants to checkout the same branch from another remote.

Kherae commented 6 years ago

I'm having a similar issue to this (possibly the same, terminology is still new to me), though with forks. I've a separate fork from a project, rather than a branch. I get the same error when trying to switch to upstream/master.

shiftkey commented 6 years ago

A potential solution for this would be to, in cases where an existing local branch exists and will clash, use the convention {remote}-{branch} when the user wants to checkout the same branch from another remote.

Taking this a step further, rather than introducing a magic convention here would it be helpful to explain the problem and let the user choose what to name the branch (with a sane default)?

The words in here are just something I threw together in haste, but I wanted to demonstrate the flow that might help address the bug and better support users working with multiple remotes.

theFisher86 commented 6 years ago

Having the same issue... surprised there's not a fix here

TizianoNoto commented 6 years ago

I'm having a similar issue to this (possibly the same, terminology is still new to me), though with forks. I've a separate fork from a project, rather than a branch. I get the same error when trying to switch to upstream/master.

I confirm. I have a fork project and I can't checkout "upstream/master" because of this issue. I have to open Git GUI to see what's changed.

shiftkey commented 6 years ago

Adding user-research to this label as we got a few 👍 to my suggestion above from a few months ago but unclear on next steps.

danilaml commented 6 years ago

I've just moved from GitHub for Windows app and this issue is really frustrating to me. In GH4W there was no such problem. You could see upstream/master branch and switch/checkout it without any problem. It'd be "checked out" as exactly this, upstream/master, no issue here, everything works as expected.

I liked and used this feature a lot, because that way you could easily develop in your own fork, branching from upstream/master, without all the pain of keeping your master in sync with the fork. When I needed, I could just check out remotename/branchname, branch from this and continue working.

GitHub for Desktop completely breaks this workflow for me for no apparent reason.

shiftkey commented 6 years ago

@danilaml would the solution I talked about here https://github.com/desktop/desktop/issues/4527#issuecomment-386221312 help address this limitation?

shiftkey commented 6 years ago

I'll also point out that we're tracking an upstream Git limitation about how to correctly handle remote branch names containing / - #3618 - which is why I recommended using - here rather than /. But given we use pr/{number} refs to track pull request branches (and can push to those) I think either approach is fine.

danilaml commented 6 years ago

@shiftkey If that branch's contents would be automatically synced up with the remote, and GitHub for desktop wouldn't try to push it into my fork (unless specifically asked to), I could live with that.

With GH4W, the workflow felt like you never actually "checked out" remote branch, i.e. you've just viewed it's remote state without actually modifying anything in your local repo, if that makes sense. Basically, I want a way to seamlessly view the current state of the remote and sometimes branch from it.

Btw, was there a discussion regarding git status --branch (as indicated by the last comment in linked issue)?

shiftkey commented 6 years ago

@danilaml I dusted off the old GHfW code and tested this out with my fork of Desktop, and we do create a new branch that matches the same ref (and tracking the right remote):

$ git status
On branch desktop/master
Your branch is up to date with 'remotes/desktop/master'.

nothing to commit, working tree clean

We could follow that pattern here too, but this bit

wouldn't try to push it into my fork (unless specifically asked to)

won't happen because of how Git sets up the default branches - you'd have to merge changes into origin/master to then push them up to the remote for that branch, and we don't currently support pushing arbitrary refs to arbitrary remotes.

Btw, was there a discussion regarding `git status --branch (as indicated by the last comment in linked issue)?

I'm not sure I understand - the discussion hasn't moved beyond that last comment because it requires a contribution to upstream Git (I'd love to get to it, but Priorities™).

danilaml commented 6 years ago

won't happen because of how Git sets up the default branches

That's fine. I just don't want for this pseudo-remote-branches to show up in my GH fork without me knowing. I.e. I'm fine with them being local, just not created on my origin automatically.

I'm not sure I understand

Well, the comment also talked about searching for existing discussions/asking mailing list so I'd like to follow/read that if it's been done.

danilaml commented 5 years ago

Currently I use the following workaround: switch to console/shell and checkout remote/branch manually (that works fine), when branch from that. Hopefully it'll be automated soon.

danilaml commented 5 years ago

Another thing that'd greatly simplify things (and cover 95% of my use cases with remote branches) if I was able to select some other branch from this dialog (new branch):

I can't see the reason for why there are only 2 choices. There should be a way to select arbitrary branch that you can see in branches drop-down. And that way, I'd be able to branch from remote/branch without actually checking it out into some separate local branch (I did it via command line so I don't see why It can be added to the interface).

kuychaco commented 5 years ago

I explored this a bit and decided to put it down for now in favor of other work. I'll do a brain dump here in order to capture what I thought about and discovered.

Proposed solution

Say we've forked a repo, open it in Desktop (using the "Clone or download" button), and click "Fetch origin" to ensure that the remote branch refs have been fetched.

In the branch list we see master which tracks with origin/master. And under "Other Branches" we see upstream/master.

Right now, this upstream/master is not actually referring to a local branch. It's referring to a remote branch that Git uses to track where the remote branch tip is (presumably output from git branch --remote).

Currently when the user clicks this Desktop tries to create another branch called master, which fails because we of course already have a branch called master.

Ideally, when the user clicks this, Desktop will detect that there's a clash in branch name and create a new local branch called upstream/master and set up the proper remote tracking info for this branch.

Under the hood, Desktop could run git checkout -b upstream/master remotes/upstream/master and this would produce the following config settings:

[branch "upstream/master"]
    remote = upstream
    merge = refs/heads/master

Now when the user checks the branch list they should see upstream/master in their "Recent branches" list.

Considerations

Note: Currently if I run git checkout -b upstream/master remotes/upstream/master on the command line, for some reason Desktop displays heads/upstream/master in the "Other Branches" list, and when clicked on the app puts you in detached head state. It’s not immediately clear to me why this happens. Interestingly if I name the branch upstream-master then it shows up just fine and works as expected.

Another consideration to keep in mind is -- if a user clicks a branch corresponding to an upstream remote branch that doesn't have a local branch name that conflicts, Desktop currently creates a local branch for it that does not have any upstream prefix. This inconsistency could be confusing... Here's an example to illustrate: say we have branches on our upstream remote called master and giraffe. If a user clicks the upstream/master remote branch in the list then, because there's already a local master branch corresponding to remotes/origin/master, they'd end up with a upstream/master local branch that tracks the remotes/upstream/master branch. If they click upstream/giraffe and there is not already a local branch with that name, they'll get a giraffe local branch that tracks the remotes/upstream/giraffe branch.

Also worth noting, the Desktop team discussed prompting the user for the branch name they would like to use when there's a naming conflict (per @shiftkey's suggestion here). We are leaning towards a more behind-the-scenes approach in order to spare users potential confusion if they're unaware of what the clash means or why it's happening. And we imagine that a vast majority of cases where this is an issue, a user is using a forking workflow and trying to see what's on upstream/master, so we can simply create a new branch called upstream/master or them to be able to do so (but of course generalize this to <remote-name>/<branch-name>). This would spare users some unnecessary mental cycles, and perhaps spare newer folks some confusion or intimidation.

mib-dotnet commented 4 years ago

Currently I use the following workaround: switch to console/shell and checkout remote/branch manually (that works fine), when branch from that. Hopefully it'll be automated soon.

Worked for me

csrvermaak commented 4 years ago

@kuychaco - thanks for perfectly describing the problem. I tried your solution, but unfortunately didn't get the required result.:

Under the hood, Desktop could run 'git checkout -b upstream/master remotes/upstream/master` and this would produce the following config settings:

[branch "upstream/master"]
    remote = upstream
    merge = refs/heads/master

Now when the user checks the branch list they should see upstream/master in their "Recent branches" list.

What I got after running git checkout -b upstream/master remotes/upstream/master was:

Switched to a new branch 'upstream/master'
Branch 'upstream/master' set up to track remote branch 'master' from 'upstream'.

This sounded promising. As you mentioned, the 'config' file was updated to include:

[branch "upstream/master"]
    remote = upstream
    merge = refs/heads/master

However, when I opened GitHub Desktop, I got the following:

And when I try to switch to 'heads/upstream/master', I get a detached head:

Hope you can provide some guidance? I've manually deleted the new branch in the interim. Thanks.

bls1999 commented 4 years ago

This sounded promising. As you mentioned, the 'config' file was updated to include:
[branch "upstream/master"]
  remote = upstream
  merge = refs/heads/master
However, when I opened GitHub Desktop, I got the following:

And when I try to switch to 'heads/upstream/master', I get a detached head:

Hope you can provide some guidance? I've manually deleted the new branch in the interim. Thanks.

This is happening to me too. Any guidance would be much appreciated.

steveward commented 4 years ago

From #10726:

When working with forks and PRs in general, I often have a branch that has the same name in the fork (origin) versus the original (upstream). I prefer to base all of my PRs off of the upstream variant of the branch (e.g. master), but I'm unable to check it out since I have a branch with the same name on my fork.

To avoid dirty PRs and such, I find myself going to the command line to forcibly change the upstream branch so that I don't have this problem anymore, but it would be nice to be able to both see and change the upstream branch within the UI.

Proposed solution Add new option in the "Branch" dropdown menu called "Change Tracking Branch". If that's too complex, just the ability to change the remote (via "Change Remote") or similar would still satisfy my needs.

Starli0n commented 3 years ago

I was searching for good git client for my teammates.

So I gave a try to Desktop Github, to discover that I could not switch to my upstream whereas it is thanks to github that I learnt git by forking and having an upstream.

Seriously, the bug was opened since almost 3 years and it is not resolved: SHAME !! whereas it is a basic github workflow, this is a joke 😂

I do not care about command lines workaround as I am searching a UI client. Since I know git, I am waiting for a decent git UI but it seems that it is not today

Less wait again few years...

TizianoNoto commented 3 years ago

I do not care about command lines workaround as I am searching a UI client. Since I know git, I am waiting for a decent git UI but it seems that it is not today

I've always copied the repositories with GitHub Desktop and then, because of this ~feature~ bug, used Git's built-in GUI tools for updates from upstream and to check mistakes before pushing.

@Starli0n I guess you already did but, if not, take a look at other suggested third-party GUI clients and see if any of them fits your needs.

Starli0n commented 3 years ago

@Starli0n I guess you already did but, if not, take a look at other suggested third-party GUI clients and see if any of them fits your needs.

Thank you

Indeed, this is where I started as it seems to be ordered by popularity.

As I am using VSCode, I will give a try to use Git lens plugin and use an integrated version instead a third party tool.

Anyway, both are microsoft now...

Vurv78 commented 3 years ago

Pls..

Fasteroid commented 3 years ago

Pls..

shiznit304 commented 3 years ago

its been a couple of years and still no fix

ArjixWasTaken commented 3 years ago

Please fix this already.

Kherae commented 3 years ago

I am...sorely disappointed. Over three years and still unfixed says it is never going to get fixed, and this bug is a very big annoyance when working on some team projects.

IgNaCy07 commented 2 years ago

Can this get fixed already?

t3chn0m4g3 commented 2 years ago

This still seems to be unresolved 😢

zeusongit commented 2 years ago

Waiting...

vu1canic commented 2 years ago

Still waiting, I'm hoping for a fix

shiznit304 commented 2 years ago

You can merge a different way by comparing changes feature

On Thu, Apr 28, 2022 at 6:24 PM vu1canic @.***> wrote:

Still waiting, I'm hoping for a fix

— Reply to this email directly, view it on GitHub https://github.com/desktop/desktop/issues/4527#issuecomment-1112742399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6IHZH5K2R4IWOFHQVX3M3VHMM2XANCNFSM4E4NRTRQ . You are receiving this because you commented.Message ID: @.***>

Fasteroid commented 2 years ago

dear god will this ever get fixed, it's been 4 years

ArjixWasTaken commented 2 years ago

Doesn't prevent core functions

I think you really need to reconsider what "core functions" are... Checking out a remote branch is a major function, and it should be high priority.

quadrismegistus commented 2 years ago

Just ran into this. +1 please fix thank you

prateek03jan commented 2 years ago

Same issue. Please share the updates! +2 (one for my colleague)

jhallbachner commented 2 years ago

I have avoided using a GUI git client for years as I feel very familiar with the CLI interface on *nix systems, but I'm currently updating a repo (a fork of another user's primary origin) on a Windows system and thought I would give this official client a try in order to manage this repo here. Running into this bug within thirty seconds of installing the client and then discovering it hasn't been fixed for over four years leaves an appalling first impression. Software with bugs of this severity, regularly encountered by users following bog-standard workflows, should be considered abandoned and it's inappropriate to promote them as actively supported software on the site.

danielniccoli commented 2 years ago

@ArjixWasTaken is right. I cannot check out upsteam/dev, so I'm unable to merge one of the most important branches of the original repo that I am contributing to with the client. That is pretty core to me.

shiznit304 commented 2 years ago

There’s a work around. You can compare changes of your current branch to upstream and merge through that.

On Mon, Jun 13, 2022 at 1:38 PM Daniel Niccoli @.***> wrote:

@ArjixWasTaken https://github.com/ArjixWasTaken is right. I cannot check out upsteam/dev, so I'm unable to merge one of the most important branches of the original repo that I am contributing to.

— Reply to this email directly, view it on GitHub https://github.com/desktop/desktop/issues/4527#issuecomment-1154252336, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6IHZDCC4ZAXOBXWJFY77LVO553NANCNFSM4E4NRTRQ . You are receiving this because you commented.Message ID: @.***>

danielniccoli commented 2 years ago

@shiznit304 Thank you, this helps immensely!

SlyckLizzie commented 2 years ago

Still a problem when using a fork. Can't find a work around to that. This GUI is basically useless to me

shiznit304 commented 2 years ago

Use the work around

On Fri, Sep 23, 2022 at 8:38 AM Dirty Gooback @.***> wrote:

Still a problem when using a fork. Can't find a work around to that. This GUI is basically useless to me

— Reply to this email directly, view it on GitHub https://github.com/desktop/desktop/issues/4527#issuecomment-1256226135, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6IHZC3CAHRM77Y2MPWKILV7WXGFANCNFSM4E4NRTRQ . You are receiving this because you were mentioned.Message ID: @.***>

aejontargaryen commented 1 year ago

Used the workaround mentioned by @shiznit304 Its in top toolbar of GUI under "Branch"
then "compare to branch"

samuelko123 commented 1 year ago

Hi @steveward (or any maintainer),

I'm hoping to give it a crack.

There're currently two proposed solutions

I just tested solution 2 and it failed, same outcome as this comment.

Also, running git commands would result in the same "detached HEAD" issue:

Proposed Solution

It'd be based on solution 1. The concern is "we will confuse new users" by display "name clash".

The solution is better wording.

Given the "popularity" of this bug, I'd say having something is better than hoping for an ideal solution which never exists. Hope it makes sense.

desktop / desktop