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?
Related
Is it possible to use git diff to show only the commit log messages? Maybe git diff is not the right tool to use it but basically I want to see the commit messages between certain commits, and I definetely do not want to count lines to see what I want to see. I know there is git log which can show certain lines but that is not what I want. I am trying to compare Blender commits, so there are alot of stuff going on and I definetely do not want to go up and down and cut and paste logs to see what i ned.
thanks
If you want to list just the commit messages (without any other information) between two commits, you can use
git log --format='%s' <old-commit>..<new-commit>
Note that <old-commit> won't be included - use e.g. <old-commit>~..<new-commit> to have it included.
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
Resolving conflicts with fugitive is great. After reading
Painless Merge Conflict Resolution in Git, I started to think how to display changes not only on a line-level but also on word-level.
All examples / cases are based on painless_git_conflicts_resolution repo. Hub was used to make git clone command more succinct.
Fugitive with disabled diff3 conflict style.
hub clone ryrych/painless_git_conflicts_resolution fugitive_no_diff3
cd fugitive_no_diff3/
git checkout beta
git merge origin/master
vim roses.txt
:Gdiff
The result is following:
Problem is that you can only see that all lines changed in some way. This example is very short, but how many of you spotted that of has been added in line 3?
RubyMine can solve that, though not always, leaving you more than often with diff marks, and without diff highlighting. Though on this screen shot there are no diff marks, the lack of 'contrast' makes it very difficult to solve that conflicts.
Fugitive with enabled diff3 + displaying common ancestor:
Show base in fugitive.vim conflict diff stackoverflow question made me try the accepted answer, but the solution wasn't an improvement.
hub clone ryrych/painless_git_conflicts_resolution fugitive_with_diff3
cd fugitive_with_diff3/
git checkout beta
git merge origin/master
vim roses.txt
:split
:Gdiff
[Ctrl][W][J]
:Gedit :1
opendiff as a mergetool
hub clone ryrych/painless_git_conflicts_resolution opendiff
cd opendiff/
git checkout beta
git merge origin/master
git mergetool
and voilà!
This, of course, solves the problem, but makes me rely upon an external tool that was only designed for one system. To sum up: is it possible to achieve something similar in Vim as in opendiff?
I've found that on my machine (running vim 7.4) all the diffs do highlight the differences within lines. The text from :help view-diff implies that this is standard behavior. It says nothing about turning the feature on or off, only that the hl-DiffText highlight group is used for "Changed text inside a Changed line"
I would try a different color scheme, or at least try and double check that your current color scheme defines an appearance for hl-DiffText
EDIT: Apparently, the given example is actually really bad for showing word-level differences. Every line has changes in multiple places, they're very short, and there's no lines that remain completely unchanged to provide context. As you can see in the screenshots, removing the conflict marker puts all the "all my base" lines at the same line number, and the word-level differences get highlighted. You might want to try with a more complex repo/merge conflict.
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.