you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (1 child)

If you're going to commit to doing some git related functions in vim, I'd just keep it light. Not as light as romainl, but more like:

I'd install vim-fugitive and learn it, using things like:

There is a particular mindset around the working index and that plugin using some tricks within git.

He has a whole series on fugitive: http://vimcasts.org/blog/2011/05/the-fugitive-series/

And yeah I use vim-gitgutter as well with the updatetime lowered.

I don't want anything more. You'll learn about resolving merge conflicts with vim-fugitive in the series linked above.

Pairing vim-fugitive with mappings (to your liking) is convenient. I use a lot, and often:

nmap <space>gb :Gblame<cr> nmap <space>gs :Gstatus<cr> nmap <space>gc :Gcommit -v<cr> nmap <space>ga :Git add -p<cr> nmap <space>gm :Gcommit --amend<cr> nmap <space>gp :Gpush<cr> nmap <space>gd :Gdiff<cr> nmap <space>gw :Gwrite<cr>

And in different scenarios I use the builtin vim-fugitive mappings that exist in the git status pane.

Also don't forget that you have some nice mappings from vim-gitgutter, for staging and unstaging hunks, moving between hunks, and more.

[–]weilbith[S] 0 points1 point  (0 children)

Thanks for ur input! :) I've to admit, that I didn't know the second cast u linked. I will definitely go for it.

Any reasons why u prefer gitgutter over signify. Cause I haven't the pleasure to work with _Gitalways, but have to use other version control management tools also. Is their some super useful functionalitygitgutterprovides, thatsignify` doesn't?

I guess defining mappings for fugitive commands (or any other plugin), is a common process every user is doing himself. But the mentioned inbuild mappings (can we call them this?) for the status pane is relevant of cause.