10

When calling magit-push-current with P P from the status buffer, Magit 2.1.0 asks me where to push the branch on the first time, when upstream is not set.

How can it let automatically generate the name as it used to do before?

  • 2
    In case you don't know, the auto-generated name is one of the completion options. So, the first time you push some-branch-name to the origin remote, you can probably just type o TAB s TAB and you'll get the name you want. – Malabarba Jul 7 '15 at 14:20
  • Oh ok I didn't know, thank you. The problem is that I have a lot of branches starting with the same prefixes, which is not very handy, also I always put on remote branches with the same name as the local branches. – z1naOK9nu8iY5A Jul 7 '15 at 14:58
8

Update: The "push branch" mentioned below has been implemented by now.See the documentation about branching for more information.

You have to set the upstream branch once. Once you have done that P P pushes to that and you will get lists of unpulled and unpushed changes in the status buffer (provided there are any).

There are various ways to set the upstream branch. You could use the --set-upstream switch from the push popup: P -u P. Or use the command which sets the upstream and does nothing else: b u.

Also Magit now automatically sets the upstream branch when creating a new branch, provided the "starting point" is a branch name. This works for local and remote "upstreams". But note that if you pick a local branch as the starting point, then that won't help you with pushing. Pushing from the current repository to the current repository obviously doesn't make sense, and is disallowed.

So when the "upstream" branch is in fact another local branch, then P P behaves as if no upstream branch were configured, and behaves exactly like P e. The same is the case if no upstream is configured at all.

This due to a limitation in Git: one can only associate one other branch with some branch, and that branch is then called the "upstream branch". It would be better if there were at least an "upstream" and a "publish" branch. I intend to implement that in Magit eventually. See issue #1485.

So if you want to be able to push with just P P then the "upstream" branch has to be e.g. "origin/master", not "master".


I am considering adding a push variant which always runs just git push without any arguments. What that does would then depend exclusively on Git configuration.

  • I branched from master and it didn't set upstream, should I maybe branch from origin/master to have the upstream automatically set? – z1naOK9nu8iY5A Jul 7 '15 at 16:23
  • See updated answer. – tarsius Jul 7 '15 at 16:45
  • 1
    Branching from origin/master set origin/master as upstream, but I would have expected to have origin/branch-name as upstream. – z1naOK9nu8iY5A Jul 7 '15 at 16:54
  • If that's what you want then it is best to do it during push. P -p P <... completion ...> RET Note that origin/branch-name is offered as a completion candidate, so you don't have to type it out. – tarsius Jul 7 '15 at 17:24
  • 2
    This is painful when you're using gitflow and pull requests for code review, with a branch per feature, because you typically only ever push once, and it's always to create a remote branch with the same name as the local branch. Pushing to a different named branch would be an end run around code review. – Barry Kelly Mar 17 '16 at 14:55
0

I just create the new branch with b c and then edit the .git/config file to point to origin/branch rather than monkeying around with all the magit 2 stuff, which doesn't seem to work anyway.

Change:

[branch "fix_something"]
  remote = .
  merge = refs/heads/master

To

[branch "fix_something"]
  remote = origin
  merge = refs/heads/fix_something

This works, whereas I still haven't found a key combination in magit2 that accomplishes the same thing. Trying to set the remote doesn't work because it doesn't exist on origin yet.

  • 1
    The upstream can be set using bu. But that uses git branch --set-upstream-to and as you know Git cannot set a non-existent branch as the upstream and so Magit cannot either. – tarsius Aug 31 '15 at 23:45
  • @tarsius magit 1 seemed to do what I needed it to. I'm just trying to get back some semblance of that workflow. – David N. Welton Sep 1 '15 at 16:57
3

I use the following advice which automatically enables --set-upstream when the current branch doesn't have an upstream yet:

(defun magit-push-arguments-maybe-upstream (magit-push-popup-fun &rest args)
  "Enable --set-upstream switch if there isn't a current upstream."
  (let ((magit-push-arguments
         (if (magit-get-remote) magit-push-arguments
           (cons "--set-upstream" magit-push-arguments))))
    (apply magit-push-popup-fun args)))
(advice-add 'magit-push-popup :around #'magit-push-arguments-maybe-upstream)

Combined with ido completion this allows pushing a new branch with P P RET:

;; NOTE: requires ido-completing-read+
(setq magit-completing-read-function #'magit-ido-completing-read)
  • This is so cool! Thank you very much! – z1naOK9nu8iY5A Jul 8 '15 at 8:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.