Magit set upstream origin

Question

I'm having trouble understanding how Magit handles pushing local branches to remote

I create and checkout a new branch with b c.

I make some arbitrary change, and save returning to magit with C-x g

I stage and commit the change adding a commit message.

Now I want to push.

In a terminal I would use git push --set-upstream origin <new_branch_name>

In magit, I use P and either u or p.

Reading the docs and this question it sounds like u is the right choice.

when i hit u the status buffer reads

Set upstream of third_test_branch and push there (default origin/master):

looking for another input. When I enter master it then pushes to the master branch.

any other input at this point seems to return match not found

what am I missing? Thanks

Answer 1

When you use p to set the value of branch.<name>.pushRemote "the value has to be the name of an existing remote", and so you can only enter one of those.

It's quite common for there to only be origin, in which case that is the only valid value. If you wish to add new remotes, use the Remotes popup bound to M.

Note that the remote branch for your pushRemote has the same name as the local branch, and so you are not prompted for that. (i.e. Pp on a local branch foo with a pushRemote of origin pushes it to origin/foo).

If you use u to specify the 'upstream' then you are defining both a remote (branch.<name>.remote) and a branch (branch.<name>.merge); so there you could enter, say, origin/bar as an upstream for local branch foo.

---

The approach I tend to use is:

• Local master has upstream of origin/master.
• Local feature branch foo has pushRemote of origin and upstream of local master (an upstream of origin/master is more dangerous if you accidentally push to upstream¹).
• My WIP on this feature is very regularly pushed to origin/foo (partly for backup purposes), using P p.
• At all times the status buffer shows me what I've added to foo since it was cut from master (being foo's upstream). This is one of the nice benefits of having both an upstream and a pushRemote, and is the other reason why you might choose not to use origin/master as the feature branch upstream: You may not wish to be bothered by seeing newer upstream additions until it's time to merge, and origin/master would be updated if you do a general fetch from origin, whereas local master won't be updated unless you tell it to.
• Once the feature is ready to be merged into and pushed to origin/master...
  • Pull any upstream changes to origin/master into the local master branch.
  • If necessary, rebase the foo branch onto the updated master.
  • Merge foo into local master.
  • If happy, push the new master upstream to origin/master.

¹ I also use this for added protection.