* magit.el: Autocommit on pull #1248

wants to merge 1 commit into


None yet

2 participants


This fixes the issue introduced when git requested the systematic edition of merge messages when pulling.

Before this patch git was in the background and opened the deffault core.editor to edit the messages which caused the process to stall in the background.
Pull now uses the same policy as merge, meaning the default merge message is automatically commited.

@tarsius tarsius added this to the 2.1.0 milestone Feb 25, 2014
Magit member

magit-pull might take a long time and should be run asynchronously. So the right thing to do would be to wrap with magit-with-emacsclient. But that doesn't work over tramp yet, so we cannot do that until I have implemented a workaround (see #801).

Also have a look at the new magit-merge-popup and the new magit-merge* commands on the next branch, for what I think should be done when git may invoke an editor.

This fixes the issue introduced when git requested the systematic edition of merge messages when pulling.

I don't quite understand that. Are you saying that git 1.9.0 (?) switched to using the equivalent of pull --edit by default. (I haven't updated yet).

@tarsius tarsius modified the milestone: 2.1.0 Feb 25, 2014
@tarsius tarsius added 00 minor and removed 00 minor labels Feb 25, 2014

I'm not sure when it was introduced but in git 1.8, git would not prompt the user when merging without conflicts and simply auto generate the merge message.
Now (I'm running git 1.9 but it used to be the same with late 1.8), even if there are no conflicts, git runs the core.editor to check the merge message.
Which means that it's no longer possible to pull within magit (except fast forwards)

My first try was using magit-with-emacsclient but it then seemed better to use the same behaviour as git-merge.

I'm a total LISP noob and barely got this working so I doubt I can be more helpful in checking your next branch ;)

Magit member

I guess I always use merge instead of pull in these cases, and so that has never caused problems for me. And it looks like most other users do that too, or this issue would have been opened before :-)

Anyway, if this works for you (and I don't know why it wouldn't), then please just use this patch for a while. I intend to fix this but by using magit-with-emacsclient, and as I said I first have to make that work with tramp first.

A better workaround would be to set core.editor to emacsclient though. Actually I don't think doing so should even be called a workaround. The whole magit-with-emacsclient voodoo is pretty much just a hack that is necessary because many users don't do that :-) A major benefit of doing it this way is that now git uses the running emacs as editor even if you should for once call a command (that needs an editor) from a shell instead of from magit.


I don't want to switch my core.editor because I do a lot of remote work on many servers and most of them don't have emacs installed...
But I agree it would be simpler !

The only issue I had with emacsclient is that the windows that appeared in the magit frame did not close once committed. Otherwise it worked great.

And yes I never merge (at least not often), but only pull and this has been bugging me for ages. I'll stick with my patch until you fix it.

@nmorey nmorey closed this Feb 25, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment