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

Can this get fixed already?

Waiting…

This still seems to be unresolved 😢

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.

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.

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.

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.

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…

Recently downloaded this GUI, and now I’m here because of this issue. WOW! 6 years still a problem when using multiple remotes? Is this project abandoned?

Use Fork or GitKraken instead 🤣

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

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

Recently downloaded this GUI, and now I’m here because of this issue. WOW! 6 years still a problem when using multiple remotes? Is this project abandoned?

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.

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

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

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: @.***>

Just ran into this. +1 please fix thank you

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.