git refuses to work with gvim

Hi, a few days ago I decided to switch from vim to gvim. To make use of this in most cases I added :gui to my .vimrc which should make most applications automatically switch to use gvim if they used the vim command before.

But git seems to have problems with this. If I do now a "git commit something" not the gui is opened but the console-version of vim. I could live with that for git but if I now type some commit-message in the console-version and do :x or :wq I get an error-message:

# git commit something fatal: no commit message? aborting commit. #

Also

# EDITOR=gvim git commit something fatal: no commit message? aborting commit. #

shows the same error.

Removing :gui from my .vimrc makes git behave normally again. I don't know what the problem here is: vim or git or both toghether?

I already saw screenshots of people using git with gvim. So there is a way to make them work together but what am I missing?

OS: Debian Lenny
vim: 7.1
git: 1.5.6.5

greetings

sebastian@CoLi.Uni-SB.DE writes:

The problem is that gvim returns immediately, and lets the window opened (try it in a terminal, "gvim foo.txt" returns immediately). Git expects the commit message to be written and saved when $EDITOR returns.

A quick search for "wait" in the man pages tells me that

  GIT_EDITOR='gvim -f' git commit 

works.

(BTW, this is in no way specific to Git, 99% applications calling $EDITOR will expect the same behavior)

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

...

The sad part is, every gvim user blames Git.

Every single one of my coworkers who uses Linux had gvim as their default $EDITOR and found git commit working sometimes, and not working others. Since git was new to them, they blamed git, not their $EDITOR. They also felt insulted when I told them their $EDITOR was busted and should be replaced.

Someone needs to whack gvim upside the head and fix that program to behave correctly.

On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:

Huh? What is wrong about 'gvim --nofork'?

Felipe Contreras <felipe.contreras@gmail.com> wrote:

The fact that its a command line option that isn't the default. gvim's UI here is as bad as pre 0.99 git.

People do:

	export EDITOR=gvim

and things work OK for a while, as they always open a new editor, work with the file, and then close it, killing the only running gvim session. Since gvim waits if its the only gvim process running, things seem fine. But days later when you leave a file open, suddenly the command calling $EDITOR starts failing.

I've seen it happen to a lot of people. They just start complaining about how one day "git commit" is fine, and the next day its not working. But its been weeks since they selected gvim as their $EDITOR and they can't connect the open editor window as the problem with that Goddamn Idiotic Truckload of s**t they are forced to use.

On Mon, Oct 12, 2009 at 5:25 PM, Shawn O. Pearce <spearce@spearce.org> wrote:

I've never seen it happening. For me either it aways fails (fork) or always work (nofork).

Yeah, it happened to me too, but eventually I realized what was happening. I like gvim's default behavior tough.

I personally don't see any problem... how about other SCMs?

On 10/12/2009 08:43 AM, Matthieu Moy wrote:

Hello,

Also, a :help nofork leads to gui-fork and guioptions, which tells you that you can add the following to .vimrc (not .gvimrc, see :help go-f): set guioptions+=f

-- Joshua Roys

sebastian@coli.uni-sb.de, 12.10.2009:

git probably calls vi and not vim. Maybe vi doesn't respect your .vimrc?

Doesn't install Debian a vim-tiny package for vi without gui and another for vim?

Markus