When using vim-fugitive if you issue :Gstatus it splits the screen and gives you the would be git commit editor and you can move over different files that have changes and press enter to see them in the other half of the screen. I believe it is like issuing :Gedit .
I then need to issue a :Gdiff manually to split the editor in half and see the side by side diff of the file to review and or stage it.
My question is is there a way to make it automatically go to :Gdiff when I press enter, while my cursor is on a file name that has changes.
Basically trying to save some time when going through a large list of files.
You can use D or dd inside the :Gstatus window to run :Gdiff on the file under the cursor. See :h :fugitive-:Gstatus or use g? inside the :Gstatus window.
For additional help you may wan to look at Vimcasts, which has some very nice fugitive.vim series.
A complement to command line git
Working with the git index
Resolving merge conflicts with vimdiff
Browsing the git object database
Exploring the history of a git repository
Related
Hi I am trying to update one of my remote repositories. When I use commit in git bash it shows that a SWP file already exists and askes me if I want to (R)ead only the file (E)dit (D)elete. I tried editing the file, but I cannot save the changes and therefore cannot commit my changes. Any idea what is going on.
EDIT:
It's working now thanks to those that helped. In terms of the question I will try to only show the relevant information when asking questions in the future.
When you edit a file, Vim stores your changes in a "swap file" so that you can recover your work if Vim's process is killed before you could save. This can be caused by something as problematic as a system crash or, simply, by closing your terminal window while Vim is running.
If Vim is quitted "normally", it deletes the swap file it created.
If it is not, the swap file is left behind and, the next time you open the same file, Vim will notice the presence of the swap file and offer you the possibility to recover the work that you "lost" the last time Vim quitted "abnormally".
That is the interactive screen you get with the "(R)ead only the file (E)dit (D)elete" prompt.
Now, when you are starting out with stuff like Git, Vim, the command line, etc. it may happen quite often that you find yourself in an uncomfortable situation, not knowing exactly what to do to fix it. This is frankly quite normal at this stage. In those situations, closing the terminal window might seem like a good first step in going back to a more comfortable situation to start again. In some cases, however, doing so might leave a trail of hidden files and broken states that might make it harder than you hoped to get to that comfortable situation.
When you do $ git commit, Git populates a specific temporary file located in your local .git directory:
.git/COMMIT_EDITMSG
with some text describing the commit you are about to make, and opens that file with your designated editor, which is the dreaded Vim by default.
When you start editing the file, Vim creates a swap file. If you insert your commit message, write the file, and quit Vim normally, the swap file is deleted and you won't ever be prompted about it. If you close the terminal window before writing the file, the swap file stays behind and Vim will prompt you about it the next time you try to make a commit.
From there you have quite a few options…
Go into your .git directory and delete the swap file(s) manually. They should be named .git/.COMMIT_EDITMSG.swp (or .swo, .swn, etc. see :help swap-files in Vim). This should give you a clean state for the next time you do $ git commit.
Don't close your terminal window when faced with a problem. Instead, try to analyze what went wrong and look for proper ways to fix it. If you have to close the terminal window, look for stray swap files just in case.
Learn Vim's basics so that you don't have to close the terminal window when you mess up your commits. Try $ vimtutor.
Tell Git to use a text editor you are more familiar with. Search Stack Overflow, I am sure there are dozens of Q/As about that.
Configure Vim to never create swap files. You can do it in Vim's configuration file:
# in $HOME/.vimrc
set noswapfile
This won't tell it to ignore existing swap files, though, so you might want to delete them manually anyway.
Use a graphical Git client instead of the CLI.
I have been using vim-fugitive which is great but I haven't figured out a good way to work on a commit message while I am adding files. My workflow has been like this...
:Gstatus
diff the files in a vsplit with
dv
look through the diff, go to another editor compose the message and then git add the file
-
repeat for all needed additions copy the composed message from my other editor and then
cc
and paste my commit message into fugitive's commit butter. I would like to develop a way to work on the commit message as I am going through and adding the files without having to get out of vim. What do you think is the best flow to accomplish this?
I use git and gitk a lot. Recently, I found some enthousiastic posts about tig and decided to give it a try.
It looks great for viewing the repository, however changing the repo with tig seems difficult if not unworkable.
The problem I am facing is that tig fails to start an editor for external commands, thus making it impossible to continue with the action.
For example, if I select a commit and issue
!git commit --amend
I get a screen saying
vim: Warning: Output is not to a terminal
Only ^C gets me out, thus stopping tig as well.
What can I do to configure this properly for either tig or git in order to get this working?
thanks in advance,
Ruud
The main way to start external commands is via keybindings and what in Tig is referred to as user-defined commands. For example, to amend the last commit you can add the following to ~/.tigrc after which pressing + will put you right into Vim:
bind generic + !git commit --amend
There are several variables for the browsing state, which can be passed to external commands, such as %(commit) and %(branch) as well as %(prompt) for asking for input, for example when creating a branch.
For reference, the !<command> allows to open the output in the pager, for example !git show 3e3abcd and as such is more like Vim's :r!<command>.
I have set vim as the svn editor.
Now, whenever I do 'svn ci', it opens up vim editor allowing me to enter the commit comments.
Below the comment section, there are set files which will be checked in. So, If I don't want certain files to be committed, I remove it from the list of files in the vim editor. But when I save and quit the vim editor, svn still checks-in the file I have removed in the editor.
Is this expected behavior? Or I need to set something in the svn configuration to make it work?
That list of files in the comments section is... well... just comments. It doesn't really do anything - it's just there to help you by letting you see what you are committing.
If you want to not commit certain files, you have to do it beforehand:
You can specify the files you want commit in the svn commit command instead of committing everything.
You can add the ignored files to your svn:ignore property.
You can use some GUI tool that'll let you visually select what to commit and what not.
There is some trick with changelists. Haven't tested it(I don't use SVN since it's crap), just found it in this answer when I googled.
Use Git with git-svn, and simply git reset HEAD the files you don't want to commit to unstage them.
The list in the editor is just informative; it tells you what will be committed but does not influence what will actually be committed (the relationship is the other way round). If that's not what you wanted, you have to kill the svn ci (typically by doing Ctrl+Z and then issuing the kill at the command line). To change what is committed, you need to list the files explicitly to svn ci; it only defaults to all known, modified files (i.e., those listed when you run svn status).
If the above way of working isn't to your taste, you might be better off getting one of the many GUIs that wrap around SVN. They almost universally make interactively selecting what to commit easier.
Suppose I generate diff of my project before commit, let say using svn. Having one diff for all files in project is a very nice way to review changes before committing them. However sometimes I wish to edit those changes without reopening each file, simple edit the diff and have it reapplied. So I have made such key map(I have setup svn diff to use unified format with fair amount of surrounding lines):
map scde :w! tmpdiff<cr>:!svn revert -R .<cr>:!patch -p0 <tmpdiff<cr>
It works, but only partially; you can edit added lines, but if you mark lines as removed or want to add another line you get some trouble since specified diff ranges do not match with actual text present in the diff. One can update them for simple changes like adding a line, however it is tedious and quickly gets complicated if you make more sophisticated changes. Is there a way to edit diff in so that range would automatically update correctly? I have found that emacs has some diff mode for this(however I have not tried it), however I was unable to find solution for my needs using vim. Maye there someone can give some suggestions?
take a look at rediff. It automatically fixes the offsets within a patch file.