"Push origin" pushes to the remote master branch

Description

After branching off origin/master and committing some changes to the new branch, “Push origin” pushes the commits to the remote master branch, instead of just pushing the current branch to a remote branch with the same name (as git push would do).

Version

GitHub Desktop version: 0.6.2

OS version: macOS 10.12.5

Steps to Reproduce

1. git checkout -b test-push origin/master
2. echo 'test' > test.txt
3. git add test.txt
4. git commit -m "testing"
5. In GitHub Desktop, check that “test-push” is showing as the Current Branch.
6. In GitHub Desktop, click “Push origin”.

Expected behavior:

The current branch should be pushed to the remote repository, as if I’d run git push.

Actual behavior:

! [remote rejected] test-push -> master (pre-receive hook declined) - luckily the remote master branch is protected, otherwise it would’ve been updated!

Logs

Here’s the relevant line from the logs:

info: [ui] Executing push: git -c credential.helper= push origin test-push:master --progress

Additional information

In ~/.gitconfig I have the following:

[push]
        default = current

GitHub Desktop seems to be acting as if this is set to “upstream” rather than “current”?

[lucascosti]

👋 @billygriffin I’ll add a +1 to this affecting me, too.

I usually have my branches track origin/master to easily see how far I am ahead/behind. But with push.default set to simple (git’s default as of 2.0), I know git push would never allow pushing directly to master without me manually doing it.

Recently, I was using Desktop to write some co-authored commit messages (which Desktop makes extremely friendly! 🚀 ), but I accidentally clicked the ‘Push’ button, and was shocked to see that Desktop pushed my branch’s changes to our production master. 😱

So I think the problem here is that we don’t respect the push.default configuration since we explicitly specify the target branch.

Yep, I think it’s dangerous to not respect git defaults without at least notifying/warning the user, especially so when it involves pushing to default branches like master.

Since this doesn’t look like a scenario you could get into without going to the command line I’m not going to classify this as a bug and by the looks of how complex this issue is we’re not going to be able to spend time on it as part of our current roadmap.

🤔 I can understand this point, but I don’t agree on an all-or-nothing approach to assuming Desktop use.

In my case, I would like to use both the CLI and Desktop at the same time: I mostly create and push branches from the CLI, but Desktop is great if I need a GUI to view history or write a fancy commit message.

❓ Possibly silly question: Forgive me if I’m incorrect, but it looks like you can’t set up tracking branches from within Desktop: so, why does Desktop make assumptions on where to push if there is a tracking branch specified and it overrides the default git behavior?

IMHO, a warning that you’re about to push to the repository’s default GitHub branch would great regardless of the scenario. In this tracking branch situation, a prompt with a choice on what to do would be even better.

Sorry for the long post! 🙇‍♂️

[hubgit]

No worries, thanks @billygriffin - I’ve learned to only create branches in GitHub Desktop now 😄