Re: git refuses to work with gvim

sebastian@CoLi.Uni-SB.DE writes:

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

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
http://www-verimag.imag.fr/~moy/

Matthieu Moy [off-list ref] wrote:

The problem is that gvim returns immediately

...

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

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.

-- 
Shawn.

On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce [off-list ref] wrote:

Matthieu Moy [off-list ref] wrote:

quoted

The problem is that gvim returns immediately

...

quoted

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

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.

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

-- 
Felipe Contreras

Felipe Contreras [off-list ref] wrote:

On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

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

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

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.

-- 
Shawn.

On Mon, Oct 12, 2009 at 5:25 PM, Shawn O. Pearce [off-list ref] wrote:

Felipe Contreras [off-list ref] wrote:

quoted

On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

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

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

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 never seen it happening. For me either it aways fails (fork) or
always work (nofork).

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.

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?

-- 
Felipe Contreras

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

sebastian@CoLi.Uni-SB.DE writes:

quoted

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

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)

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