A noob question, exiting out of Gdiff #36

Closed
wavded opened this Issue Feb 3, 2011 · 44 comments

Projects

None yet
@wavded
wavded commented Feb 3, 2011

Love this plugin, but one thing I can't figure out is how to stop doing a Diff. If I use:
:Gdiff
It will split my windows out and let me do that, but how to do I exit that. I've tried:
:diffoff
But that doesn't get me back to my original file and remove the other "orig" version. Any tips? Thanks.

Marc

@tpope
Owner
tpope commented Feb 4, 2011

Close the other window. The easiest way to do this if you haven't shifted focus to it is <C-W><C-O>, which means "make this Window the Only window."

@tonylotts

I'd say Issue 76 (open diff in new tab) could be a possible solution in the interim, but I think there should be an easier way to close the diff window, and get back to where you were.

As it is now there are two ways to go about this:

  • <C-W><C-O>, then :diffoff
  • Open diff in new tab, then close tab.
@tpope
Owner
tpope commented Jan 31, 2012

You shouldn't need the :diffoff. Fugitive bends over backwards to attempt to close it for you.

@tonylotts

I did some tests, and there is one edge case.

  • If there are differences when running Gdiff, <C-w><C-o> works as intended.

  • However, if there are no differences to display, one must press <C-w><C-o> then run :diffoff.

    As time allows, I'll see if I can fix it and submit a pull request.

@tpope
Owner
tpope commented Feb 1, 2012

@tonylotts, no such distinction when I try here. I never need :diffoff, and I can't think of anything off the top of my head that would cause such an edge case.

@blueyed
Contributor
blueyed commented Aug 30, 2012

:only (which is what `C-W C-O does) has the main disadvantage that it will close any other windows you might have open, too.

It would be nice to have q (or something else) mapped in the windows opened by fugitive's diff action, which would take care of bringing you back to e.g. ":Gst".

@tpope
Owner
tpope commented Aug 30, 2012

This is true of any window, really. My rule is only to map q in read only buffers.

@blueyed
Contributor
blueyed commented Sep 26, 2012

I just stumbled upon an older entry in my vimrc about this (but not used recently).

Maybe you feel like adopting it into fugitive directly somehow:

" vimdiff current vs git head (fugitive extension) {{{2
nnoremap <Leader>gd :Gdiff<cr>
" Close any corresponding diff buffer
function! MyCloseDiff()
  if (&diff == 0 || getbufvar('#', '&diff') == 0)
        \ && (bufname('%') !~ '^fugitive:' && bufname('#') !~ '^fugitive:')
    echom "Not in diff view."
    return
  endif

  " close current buffer if alternate is not fugitive but current one is
  if bufname('#') !~ '^fugitive:' && bufname('%') =~ '^fugitive:'
    if bufwinnr("#") == -1
      b #
      bd #
    else
      bd
    endif
  else
    bd # 
  endif
endfunction
nnoremap <Leader>gD :call MyCloseDiff()<cr>
@sheerun
sheerun commented Feb 13, 2013

I need to call :diffoff too..

@tpope tpope reopened this Feb 13, 2013
@tpope
Owner
tpope commented Feb 13, 2013

Forced into Janus at my current client and I'm having the same issue. Haven't had time to debug it but I give ten to one odds on a plugin conflict.

@hkjels
hkjels commented Mar 6, 2013

I'm not using janus, but still have to use :diffoff.
Weird thing though; it's not the diff-mode that persists,
it's my code being folded at the first level.
:diffoff releases that fold and all things are back to normal.

@Peeja
Peeja commented Mar 11, 2013

Thought: Perhaps a :Gclose command would be useful? It could close all other revisions of the current buffer's file.

@aaronmcadam

@Peeja massive +1 for that, it's the most frustrating part of using :Gdiff!

@sheerun
sheerun commented Mar 11, 2013

+1 for :Gclose

@tpope
Owner
tpope commented Mar 11, 2013

I'm not adding a "work around a broken setup" command. Someone needs to do the legwork to find the plugin we're at odds with.

@Peeja
Peeja commented Mar 11, 2013

@tpope To clarify: This isn't to solve the foldlevel issue. This is a quick way to get out of :Gdiff if you have other windows in the tabpage you'd like to keep open.

@Peeja
Peeja commented Mar 11, 2013

Let's move discussion of getting stuck in diff-mode / with folds folded to #317, since it's not the topic of the original post here.

@tpope
Owner
tpope commented Mar 11, 2013

@Peeja, "stuck in diff-mode" and "folds closing" are two different issues. I'm keeping the former here because it's what the original author was experiencing.

@tpope
Owner
tpope commented Mar 11, 2013

Regarding the actual workflow issue, I think the issue would mostly go away if we just focused the diff window by default, no? Only caveat is it's hard to select the right line.

@Peeja
Peeja commented Mar 11, 2013

@tpope Ah, I misunderstood. That's hairier, then. :)

Re: the workflow, I'm not sure I understand what you're saying. Which window is the diff window, and when should it be focused by default?

@tpope
Owner
tpope commented Mar 11, 2013

The opposite of the one that it is now. Which is almost always the one you want to close.

@Peeja
Peeja commented Mar 11, 2013

Oh, I see, focus that window after it opens with :Gdiff?

That would probably be nice. It solves another workflow issue: writing the
index buffer when staging a commit by patches.

@Peeja
Peeja commented Mar 15, 2013

For the past couple of days I've been immediately switching (manually) to the stage buffer after :Gdiff to see what it would be like. I really like it. I just have to train myself to use do instead of dp to stage changes.

My usual flow now:

  1. :Gdiff
  2. <C-w><C-h> (Switch to stage buffer.)
  3. gg (Go to the top of the file.)
  4. ]c (Go to next change.)
  5. do, if I want to stage the change.
  6. Repeat from Step 4 until I get to the bottom of the file.
  7. :wq
  8. If I'm ready to commit, :Gcommit

It feels pretty smooth.

@blueyed
Contributor
blueyed commented Mar 15, 2013

@Peeja
you might want to try my "gd" and "gD" mappings then: ",gd" for ":Gdiff" and ",gD" to close the diff (via a function); I have mentioned this above already, but here's a link again: https://github.com/blueyed/dotfiles/blob/master/vimrc#L1067

@Peeja
Peeja commented Mar 15, 2013

@blueyed How do you write the buffer before closing it?

@blueyed
Contributor
blueyed commented Mar 15, 2013

Vim asks me, if I want to write the changes (if there are any).

@yevgenko

I've posed the similar question on SO, ended up with the following mapping:

nnoremap <Leader>gD <c-w>h<c-w>c
@sheerun
sheerun commented Apr 14, 2013

I think this should be the default...

@bbinet
bbinet commented Apr 17, 2013

I'm also facing this :Gdiff workflow issue.
+1 for focusing the diff window by default.

@cspiegel

After a recent vim upgrade, the automatic reopening of folds after closing a :Gdiff window stopped working for me. I tracked it down to patch number 7.3.801 (ftp://ftp.vim.org/pub/vim/patches/7.3/7.3.801).

I just built vim 7.3 with all patches but 801 (918 being current as of right now), and my folds are unfolding again. Whether this is a bug in the patch or a bug in fugitive is the question, of course.

@fantattitude

+1 What @cspiegel found seems interesting ๐Ÿ˜ƒ

@tommcdo
Contributor
tommcdo commented Sep 11, 2013

I'd like to bump this issue up if possible. I haven't pulled on this plugin in a while and came here to see if this was fixed (or identified as a Vim bug) yet. I'm now running Vim 7.4 and the problem persists.

Has anyone done the legwork to determine whether this is a Vim bug or a Fugitive bug?

@tpope
Owner
tpope commented Sep 11, 2013

@tommcdo I already said the problem is probably a conflicting plugin. You want it fixed, find the plugin.

@tommcdo
Contributor
tommcdo commented Sep 11, 2013

@tpope, I tested with no other plugins loaded and an empty .vimrc (except for call pathogen#infect()) and closing the revision buffer does not remove the diff folds. It seems @cspiegel is onto something about patch 801, as this only started happening for me when I upgraded from patch ~400 to ~900, and as I said, it persists in 7.4. So I think it remains to be determined whether this is a bug introduced by 801 or a bug in Fugitive.

@tommcdo
Contributor
tommcdo commented Nov 20, 2013

I used git bisect to find out when this stopped working, and it seems to have been here:

a0f5c04

Commit message seems relevant, I'd say it's a likely culprit.

@tommcdo
Contributor
tommcdo commented Nov 20, 2013

But if I could reiterate a point brought up before, this issue doesn't exist in Vim versions older than 7.3.801. (I'm guessing at the exact patch, again going on what @cspiegel said.) I tested in Vim 7.3.429 (with the exact configuration I use in Vim 7.4.005) and it worked as expected. So it seems to be the combination of the changes introduced by a0f5c04 and the changes introduced by Vim patch 7.3.801.

@tommcdo
Contributor
tommcdo commented Dec 30, 2013

Here's a demonstration of this behaviour with all other plugins and custom configuration disabled:

http://asciinema.org/a/6970

@tpope
Owner
tpope commented Dec 30, 2013

Okay, so the unfolding issue is most definitely a different issue I overlooked in the page after page of comments. It looks like the actual change in vim is that set foldmethod=manual used to clear out the old folds, but now it leaves them intact. Right?

@tommcdo
Contributor
tommcdo commented Dec 30, 2013

Looks like that's probably it. Is there a way to capture all folds at the time of a :Gdiff and restore them afterward? Seems kinda cumbersome though :/

@tpope
Owner
tpope commented Dec 30, 2013

Yeah no problem I'll just store them all on the SPACE SHUTTLE THAT VIM ALSO SHIPS WITH.

@tommcdo
Contributor
tommcdo commented Dec 30, 2013

Would it be acceptable to just clear them? That's how it behaved before. And I guess it would actually be pretty unreasonable (as a user) to expect that your original folds are restored after entering a diff.

@tpope tpope added a commit that referenced this issue Dec 30, 2013
@tpope Reopen diff folds when diff ends
References #36.
1b0ddad
@tpope tpope added a commit that referenced this issue Dec 30, 2013
@tpope Focus diff window on :Gdiff
References #36.
546a6bf
@tpope
Owner
tpope commented Dec 30, 2013

Yes, and that's what I've done. I'm also pushing up my previous attempt to focus the diff window on :Gdiff. I was unsatisfied with the cursor position when I last worked on it, but I guess it's still a step in the right direction.

@tpope
Owner
tpope commented Dec 30, 2013

Oh, and btw, there's a good chance this fixed the original issue too. So good, in fact, that I'm closing this issue until someone objects.

@tpope tpope closed this Dec 30, 2013
@tommcdo
Contributor
tommcdo commented Dec 30, 2013

Awesome, thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment