3

Reading the Magit user manual, there is an entry on pushing the current branch to its upstream branch, by pressing P P. This is not working for me, as I get P isn't bound to any action on the second P press. Same issue for F F as well. Anyone else having the same issue?

(magit-version): Magit 20151208.1407, Git 2.6.3, Emacs 24.5.1

Emacs installed via homebrew on OS X El'Capitan: brew install emacs --with-cocoa

Improve this question
4
  • Is P u bound?
    – wasamasa
    Dec 10, 2015 at 19:40
  • Yes, that is how I do it now
    – jmbond
    Dec 10, 2015 at 19:45
  • I noticed in the most recent version of magit as well. It seems like the functionality has changed so that you use P e to set the upstream branch, and then P u to push to it afterwards. Same goes for the fetch commands. I prefered the old way, but I have quickly gotten used to the new way too.
    – elethan
    Dec 10, 2015 at 19:59
  • No you usually shouldn't do that. Instead you should push to the push-remote. See the Branching info node for more information.
    – tarsius
    Dec 10, 2015 at 21:06

2 Answers 2

Reset to default
3

Magit did change a few keybindings recently to make operations like pushing and pulling less dangerous.

See this commit for a summary of what changed.

Improve this answer
0
5

Starting with v2.4 (or "a few days ago" if you use Melpa (non-stable, i.e. a development snapshot)) Magit supports the push-remote in addition to the upstream branch.

You should read the Branching info node to learn about the push-remote, how it is different from the upstream, and how to configure it all. I'll likely write a tutorial about branching before releasing v2.4, and also update this answer.

Edit: You can get the P P binding back if you really want to:

(magit-change-popup-key 'magit-push-popup   :action ?p ?P)

and to restore the other same-key-twice bindings

(magit-change-popup-key 'magit-fetch-popup  :action ?u ?f)
(magit-change-popup-key 'magit-pull-popup   :action ?u ?F)
(magit-change-popup-key 'magit-rebase-popup :action ?e ?r)

But that has downsides too:

  • This just restores the bindings, the commands they are bound to by this are not in all cases identical to the old commands. For example P P used to push to the configured upstream or if no upstream was configured it asked where to push to. Now it pushes to the push-remote or if that is undefined, it offers to set the push-remote and then pushes to it.

  • While it will take some time to get used to, the new default bindings also have the potential to make it into muscle memory. I think it is a nice property of the new bindings, that from all of these popups p will do something with the push-remote and u will do something with the upstream branch.

Another alternative would be:

(magit-define-popup-action 'magit-push-popup ?P
  'magit-push-implicitly--desc
  'magit-push-implicitly ?p t)

(define-key magit-mode-map "f" 'magit-pull-and-fetch-popup)
(define-key magit-mode-map "F" nil)

  • With that, P P would once more push to "the most reasonable place possible". Again this is not the same command these keys were previously bound to, but this might be an approach that users who do not want to use the push-remote might like. This command just calls git push without a refspec, so what will happen depends on a variety of Git variables. (For that reason I consider it to be somewhat risky and don't add it to the popup by default.) See the doc-string for more information.

  • And it would once more be possible to fetch by pressing the same key twice (but that key would be f, not F and that would also fetch all remotes instead of just the current remote as before).

Improve this answer
1

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.