Ease your git workflow within vim.
From a very single vim buffer, you can perform main git operations in few key press. To name a few:
Take a look at TL;DR to start using it immediately. If you encounter any performance issue, take a look in the section performance.
Some screencasts:
This workflow is 100% inspired from magnificent emacs Magit plugin.
More to come:
Why should I use vimagit, there are already plethora git plugins for vim?
This is the minimal required set of command you must know to start playing with vimagit. See Mappings for a complete description.
To simply test vimagit, modify/add/delete/rename some files in a git repository and open vim.
:Magit
<C-n>
<C-n>
, or move the cursor as you like. The cursor is on a hunk.S
S
in Normal mode: the hunk is now staged, and appears in "Staged changes" section (you can also unstage a hunk from "Staged section" with S
).CC
CC
.
CC
(or :w
if you prefer).You just created your first commit with vimagit!
For various reasons, vimagit may be slow to refresh. A refresh happends every time you stage, unstage, commit or refresh the vimagit buffer. Currently, vimagit is quite dumb: every time the buffer is refreshed, it dumps everything and reconstruct the entire buffer. It could be smarter, but there are a lot of corner cases and it is quite a big work.
vimagit tends to be slow when:
Possible solution:
let g:magit_default_fold_level = 0
Change the default fold level. When fold level is set to 0, diff content are not print in the buffer. The buffer will show the files containing diffs. If you want to see the diff relative to file, move the cursor to the filename, and press<Enter>
.
In a near future, vimagit may try to be smart, and adapt the foldlevel automatically, based on the bumber of diff lines.
Any contribution is welcomed. Contribution can be bug fix, new feature, but also feedback or even tutorial! Check contribution rules here.
Now that stage feature is quite mature, I would like to introduce more commands to vimagit. For this, user feedback is very important to me, to ensure that UI is appropriate for the most of users and that vimagit fits most of git workflows (by UI, I mean default mapping, user prompt, etc.).
Proper way to discuss is on gitter and on issues opened for the new features.
The next major release of vimagit will see 3 new important features. Interested users are encouraged to discuss the best way to design these new features:
<CP>
. magit will detect the default push branch; if there is not default, or if the user used another mapping, magit will provide a way to select remote branch to push #24 <CH>
. Like for push, a UI must be designed to select the branch, with completion of course #141 Thanks for your time.
This plugin follows the standard runtime path structure, and as such it can be installed with a variety of plugin managers:
git clone https://github.com/jreybert/vimagit ~/.vim/bundle/vimagit
NeoBundle 'jreybert/vimagit'
Plugin 'jreybert/vimagit'
Plug 'jreybert/vimagit'
call vam#ActivateAddons([ 'jreybert/vimagit' ])
vimagit buffer has modes. Mappings may have different behavior, depending on current mode and cursor position.
For the moment, vimagit counts only two modes.
This is the default mode. In this mode, you can stage and unstage hunks, refresh vimagit buffer...
In this mode, "Commit message" section is open, you can write your commit message and validate your commit.
Commit mode has two flavors.
By the way, you can also perform all stage mode actions in commit mode.
IMPORTANT: mappings can have different meanings regarding the cursor position.
There are 5 sections:
It is possible to stage and unstage part of hunk, by different ways:
Visual selection and marked lines have some limitations for the moment:
Function to open magit buffer. This buffer will handle the git repository including focused file. It is possible to handle multiple git repositories within one vim instance.
It takes 3 parameters:
Open magit buffer in a vertical split (see details).
Open magit buffer in current window (see details).
You can create a bash alias like magit="vim -c MagitOnly"
For each mapping, user can redefine the behavior with its own mapping. Each variable is described in vimagit help like vimagit-g:magit_nameofmapping_mapping
Following mappings are broadly set, and are applied in all vim buffers.
Open Magit buffer
Following mappings are set locally, for magit buffer only, in normal mode.
Some mappings are set for the whole magit buffer, others are set for specific section only.
CC, :w :x :wq ZZ
CA
CF
Ctrl+n,Ctrl+p
Enter
zo,zO
zc,zC
R
- , + , 0
q
?
S
F
L
M
DDD
I
E
If cursor is in a hunk, cursor will move in the file containing this hunk, at the line of the beginning of the hunk.
E means 'edit'.
:exclamation: this function is extremely powerful, just give it a try!
CC, :w :x :wq ZZ
CA
CU
Since vimagit 1.7, jump mappings have changed:
Magit will raise some events at some point. User can plug some specific commands to these events (see example.
This event is raised when the magit buffer is initialized (i.e. each time magit#show_magit() is called.
This event is raised every time the magit buffer is refreshed, event if no file is updated.
This event is raised each time a file status is updated in magit buffer
(typically when a file or a hunk is staged or unstaged). The variable
g:magit_last_updated_buffer
is set to the last updated file, with its
absolute path.
Note: g:magit_last_updated_buffer
will be updated and VimagitUpdateFile event will
be raised only if the buffer is currently opened in vim.
This event is raised when the commit section opens and the cursor is placed in this section. For example, the user may want to go straight into insert mode when committing, defining this autocmd in its vimrc:
autocmd User VimagitEnterCommit startinsert
This event is raised when the commit section is closed, because the user finished to write its commit message or canceled it. For example, the user wants to set the |textwidth| of the vimagit buffer while editing a commit message, defining these |autocmd| in vimrc:
autocmd User VimagitEnterCommit setlocal textwidth=72
autocmd User VimagitLeaveCommit setlocal textwidth=0
The following example calls the vim-gitgutter refresh function on a specific buffer each time vimagit update the git status of this file.
autocmd User VimagitUpdateFile
\ if ( exists("*gitgutter#process_buffer") ) |
\ call gitgutter#process_buffer(bufnr(g:magit_last_updated_buffer), 0) |
\ endif
The following example is already embeded in vimagit plugin (see g:magit_refresh_gitgutter), then you shouldn't add this particular example to your vimrc.
User can define in its prefered vimrc some options.
Choose display setup for magit (default: 'v') Possible values: 'v': vertical split 'h': horizontal split 'c': current buffer
let g:magit_show_magit_display='v'
To enable or disable vimagit plugin. Default value is 1.
let g:magit_enabled=[01]
Git command, may be simply simply "git" if git is in your path. Defualt is "git"
let g:magit_git_cmd="git"
To disable chatty inline help in magit buffer (default 1)
let g:magit_show_help=[01]
Text is grayed if first line of commit message exceed this number of character (default 50)
let g:magit_commit_title_limit=[0..300]
When this variable is set to 0, all diff files are hidden by default. When this variable is set to 1, all diff for modified files are shown by default. When this variable is set to 2, all diff for all files are shown by default. Default value is 1. NB: for repository with large number of differences, display may be slow.
let g:magit_default_show_all_files=[012]
Default foldlevel for magit buffer. When set to 0, both filenames and hunks are folded. When set to 1, filenames are unfolded and hunks are folded. When set to 2, filenames and hunks are unfolded. Default value is 1.
let g:magit_default_fold_level=[012]
When stage/unstage a hunk, cursor goes to the closest hunk in the same section. This option automatically opens the fold of the hunk cursor has jump to. Default value is 1.
let g:magit_auto_foldopen=[01]
With this variable, the user is able to choose which sections are displayed in magit buffer, and in which order. Default value:
let g:magit_default_sections = ['info', 'global_help', 'commit', 'staged', 'unstaged']
This variable is the maximum number of diff lines that vimagit will display without warning the user. If the number of diff lines to display is greater than this variable, vimagit will ask a confirmation to the user before refreshing the buffer. If user answer is 'yes', vimagit will display diff lines as expected. If user answer is 'no', vimagit will close all file diffs before refreshing. Default value is 10000.
let g:magit_warning_max_lines=val
When set to 1, discard an untracked file will indeed delete this file. Default value is 0.
let g:magit_discard_untracked_do_delete=[01]
When set to 1, and if vim-gitgutter plugin is installed, gitgutter signs will be updated each time magit update the git status of a file (i.e. when a file or a hunk is staged/unstaged). Default value is 1.
let g:magit_refresh_gitgutter=[01]
When set to 1, magit buffer automatically closes after a commit if there is nothing else to stage (which means that both Staged and Unstaged sections are empty). Default value is 0.
let g:magit_auto_close=[01]
This part must be refined, I don't see any minimal version for git and vim, but for sure there should be one.
At least, it is tested with vim 7.3.249 and git 1.8.5.6 (see Integration).
Branches master and next are continuously tested on travis when published on github.
vimagit is tested with various versions of vim on linux: vim 7.3.249, vim 7.4.273, and latest neovim version. It is also tested for macos X: vim, macvim and neovim. Anyway, if you feel that vimagit behaves oddly (slow refresh, weird display order...) please fill an issue.
For the most enthusiastic, you can try the branch next. It is quite stable, just check its travis status before fetching it.
Travis status:
A lot a features are developed in dev/feature_name branches. While it may be asked to users to test these branches (during a bug fix for example), one is warned that these branches may be heavily rebased/deleted.
Pull requests are very welcomed. Some good practice:
next
branchCopyright (c) Jerome Reybert. Distributed under the same terms as Vim itself. See :help license.