Skip to content

:only goes to wrong buffer when :Gdiff after :Gstatus #66

dlee opened this Issue May 7, 2011 · 13 comments

5 participants

dlee commented May 7, 2011

To reproduce:

  • Edit and save a file
  • :Gstatus and press enter on modified file
  • :Gdiff inside the window of the modified file
  • :only inside the window of the working version (right window)

I expect the resulting window to be on the working version.

The resulting window is actually on the old version.

tpope commented May 7, 2011

I can't reproduce this. Perhaps another plugin is involved?

wadey commented Aug 26, 2011

I can get this to happen quite often, something like the following flow:

  1. :GStatus
  2. D on a modified file to open diff
  3. Look around, then Ctrl-W to switch back to Status window
  4. - to copy the file to the index
  5. Repeat 2-4 for a few files
  6. C to open the commit window

Now, before I close the commit window I have 3 windows open. The commit window and the two diff views below it. When I save and close the commit window, I am put into the left side of the diff view (which means that doing :only will then close the diff view but keep me in the git index version of the file)

Does that make sense?

wadey commented Aug 26, 2011

Oh, I see this issue was something stranger. What I meant to say is that it would be nice to be put back into the right window of the diff view after committing.

tpope commented Aug 26, 2011

@wadey, the same thing would happen with any 3 windows in that configuration, no matter how they were opened. It's not fugitive's place to get involved.

wadey commented Sep 12, 2011

Ok, so I can actually reproduce the original description of this bug now.

  1. :GStatus
  2. D on a modified file to open diff
  3. verify that the cursor is in the right window, but don't make any changes
  4. :on to close all but the focused window
  5. Instead of keeping the right window, the left window is kept. The fugitive:... window
tpope commented Sep 13, 2011

@wadey, please rule out any other plugins.

wadey commented Sep 13, 2011

Ok, I'll see if I can do it. Basically, it doesn't always happen, but once it happens in a window it continues until I quit.

tpope commented Sep 13, 2011

Well then I would start by killing any buffer/window management plugins (those are the biggest offenders) and seeing if the problem crops up again.

Spoygg commented Dec 20, 2011

I have this issue too.
do a D on a file in status
Go to new version (right diff)
I'm left with older version of file (left diff) (i.e. repo/.git//0/some/path/somefile.ext)

I'll try later to find a precisely what causes this.
Thanks for Fugitive :D

It's easier to go to right hand diff (old version) and do :q than to look for what is messed up. Works for me ;)


Any news on this issue? I'm having it too, but I'm afraid my Vim knowledge is far from sufficient to let me find the cause…

tpope commented Aug 28, 2012

@lunaryorn you could start by ruling out other plugins, like I requested twice.


@tpope I did… I can read, you know.

My vim configuration is blank with only pathogen and fugitive. To reproduce this issue, I did the following:

$ mkdir empty-git-repo
$ cd empty-git-repo
$ git init
$ echo "foo" > foo
$ git add foo
$ git commit -m 'foo'
$ echo "bar" >> foo
$ vim foo

Inside this vim I immediately call :Gstatus, press <Ctrl+N> to move the cursor onto foo, press D to start :Gdiff, and press <Ctrl+W><Ctrl+O> (the cursor is located in the right window, containing the working copy version). The buffer that remains is the one containing the version from the commit (buffer name fugitive://*, contents foo\n) instead the one containing the working copy version (buffer name foo, contents foo\nbar\n).

This happens in MacVim snapshot 64 as well as in system Vim of OS X 10.7.4.

@tpope tpope added a commit that closed this issue Aug 28, 2012
@tpope Fix <C-W><C-O> in diff below :Gstatus
I'll admit I can't remember the original purpose of this code.

Closes #66.
@tpope tpope closed this in 381b275 Aug 28, 2012
tpope commented Aug 28, 2012

If a tree falls in a forest and no one is around to hear it, does it make a sound?

Good news is I was able to reproduce it with the provided blank config. (I'm not sure why I couldn't with my own blank config.) It looks to happen when the status window is open above the diff windows (as opposed to 'splitbelow', which is in my normal config). I was able to fix it by deleting some code, which worries me because I know that code was there for a reason. Keep an eye out for regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.