Hot answers tagged

50

You can use :Gedit/:Gsplit/:Gvsplit/... with the form {revision}:{filename} :Gedit branch:/foo/bar.c Note: If the file is the same as the current file you can abbreviate the command like so: :Gsplit branch:%. It is often the case that a diff of the current file is preferred than just opening the file on a different branch. You can do this via :Gdiff {...


14

This is a little more broad than what OP asked, but for people not wanting to use plugins, and possibly other revision control systems, this little snippet tends to work fairly well: :new :r! git show branch:file :1d It creates a new window and shows the file there by reading the output of the given command into the new buffer. This of course works with ...


13

To culminate the answers here are the ways to accomplish this: Vanilla Terminal Vim Press CTRL-Z in normal mode will drop you back in to the shell and suspend Vim. After executing your git checkout [branchname] type the fg command to return to the suspended Vim which will also force Vim to refresh. Vanilla GUI Vim Some gvim implementations will have :...


13

Use the vim-merginal plugin (fugitive extension). It offers interactive TUI for: Viewing the list of branches Checking out branches from that list Creating new branches Deleting branches Merging branches Rebasing branches Solving merge conflicts Interacting with remotes(pulling, pushing, fetching, tracking) Diffing against other branches Renaming branches ...


11

Since 7.4, all your configuration files (even your vimrc) are expected to be in this directory: %userprofile%\vimfiles\ But the name and location of that directory only matter to Vim. From Git's point of view, that directory could as well be /etc/foo/bar/ without any impact whatsoever. So... put your vimrc and all your third-party scripts in %...


11

There might be other ways, but this approach lets you to do more than adding a chunk, which is why I tend to use it quite a lot. Run :Gdiff command. It will open a split with version of current file that's currently in the index to the left/top of the original window. While in original window (right or bottom one), perform visual selection of changes you'd ...


9

You could use the args command instead: command G execute ":args `git diff --name-only`" The first file should be opened, and if you run :ls after executing this, you should see other files listed as well. Or, as romainl notes, you don't need the execute at all: command G :args `git diff --name-only` The argadd command could be useful too. From :h args: ...


8

I used the trick from this SO question to see what the command line was, and got this: :exe '!tr "\0" " " </proc/' . getpid() . '/cmdline' :!tr "\0" " " </proc/23932/cmdline gvim -f -d -c wincmd J foo ./foo_LOCAL_23800 ./foo_BASE_23800 ./foo_REMOTE_23800 So the trick is using Ctrl-WJ (via :wincmd): :...


8

Is it possible to only have .*.swp-files, when file on disk and file in vim are different? Yes. The snippet below (adapted from tpope's vimrc) will disable the swap file for a buffer when it isn't modified, so swap files only exist for modified files. autocmd CursorHold,BufWritePost,BufReadPost,BufLeave * \ if isdirectory(expand("<amatch>:h")) |...


8

vim -r at the command line will list all swap files in the current directory and temporary directories, and whether they contain any unsaved changes. Look for the line that says modified: no/YES. I don’t know how to tell Vim to look in a different directory, so you’ll need to change to each directory that contains a swap file and run vim -r. You could come ...


7

$ git config --global core.editor "vim -Nu NONE" tells Git to use Vim without sourcing your vimrc (-u NONE) and in "nocompatible" mode (-N). And, well… you could even add something to start directly in insert mode: $ git config --global core.editor "vim -Nu NONE -c startinsert"


7

You should embrace your terminal. If you use CTRL-Z, it will background Vim (or whichever process you are currently running), then you can run any commands you want, the fg to bring the process back to the foreground: <CTRL-Z> git checkout <tab> fg


7

I think the most likely culprit is another buffer still in diff-mode. This can happen if you're looking at multiple diffs, one after another, and don't turn off diff-mode between diffs. Disable diff-mode in irrelevant buffers The solution is to find the offending buffer(s) and turn off diff-mode with :diffoff. If you don't want to search for it, you can ...


7

If I run :set spell, I get: spellfile#LoadFile(): There is no writable spell directory Shall I create /Users/adamharris/.nvim/spell (Y)es, [N]o: Select y Cannot find spell file for "en" in utf-8 Do you want me to try downloading it? (Y)es, [N]o: Select y, and it will download the file. In which directory do you want to write the file: 1. /Users/...


6

Depending on how you update your ./tags file: If you do not commit your ./tags file to your branch/repository you can use a git hook that calls ctags -R . on each pull/checkout you do - this way your ./tags file will always contain data on all present files in the current version you have checked out. If you do want to commit your ./tags file, you can ...


6

You could use the following function which has the advantage of not changing the state of your local git repo: function! CommitQF(...) " Get the commit hash if it was specified let commit = a:0 == 0 ? '' : a:1 " Get the result of git show in a list let flist = system('git show --name-only ' . commit . ' | tail -n +7') let flist = split(...


5

The fugitive Git checkout <branch> has a downside that it doesn't autocomplete the branch name. Using fzf.vim I've created this command: function! s:changebranch(branch) execute 'Git checkout' . a:branch call feedkeys("i") endfunction command! -bang Gbranch call fzf#run({ \ 'source': 'git branch -a --no-color | grep -v "^\* " ', ...


5

GitLocations won't work as expected, since you'll be calling Vim's :find, not the find command. You might try something like: return system('find $HOME -name ".git" -printf "%h\n"') And you could add a -type d to it to skip submodules. To get visually selected text, you can use getline(): let s:msg = join(getline("'<", "'>"), "\n") . "\n" However,...


5

The Gedit command is here for you. It takes an argument which is the revision you want to use, using the same logic as git-rev-parse (meaning you can use it without argument to get back to your working copy), so, on your file, type :Gedit And you're back to your working copy. References: :h fugitive-:Gedit :h fugitive-revision


5

As you specifically asked about solutions that use other plugins, I'll note that you can also stage visual selections using vimagit, which is a Git plugin (based on the other editor's popular Magit plugin) centered around viewing, staging, and commiting changes. To stage a visual selection using Vimagit: Run the :Magit command to open a new buffer that ...


5

It's possible with some scripting. When editing a commit message, a temporary file .git/COMMIT_EDITMSG is created with the contents of the commit.template file. With autocmd we can execute a script that changes the content of the buffer: function! s:expand_commit_template() abort let context = { \ 'MY_BRANCH': matchstr(system('git rev-parse --...


5

The most general improvements I can give are to avoid the long ?: and to make use of the get function on dictionaries. For example, I would write return get(g:, 'git_branch', '') For the if, use a plain if let l:is_git_dir = trim(system('git rev-parse --in-inside-work-tree')) if l:is_git_dir is# 'true' let g:git_branch = trim(system('git rev-parse --...


4

gitgutter and signify are two plugins I know of which provide this sort of functionality. When a buffer is saved, the sign column is updated to show where lines have been added/modified/deleted. gitgutter is Git specific, while signify supports multiple version control systems. N.B., I'm a collaborator on signify.


4

To view unstaged modifications to your git working tree in vimdiff, try: git difftool --tool=vimdiff or for staged changes git difftool --tool=vimdiff [ --staged | --cached ] These commands are invoking git difftool and specifying vimdiff at invocation, so should work without any prior configuration. However, until you configure vimdiff as the default ...


4

Here's a quick and dirty function that does what you request: function! UndoCommits(steps) for i in range(a:steps) undo endfor for i in range(a:steps) write execute printf('!silent git commit -am "%s"', "undo-commit" . i) redo endfor write execute printf('!silent git commit -am "%s"', "final-undo-...


4

Vimcasts has a great series on Fugitive.vim. The episode Fugitive.vim - working with the git index would be the the most helpful for your question. You can use :Gdiff to stage only portions of a file. Running :Gdiff will show you the current file "diff-ed" with the stage/index. You can simply use Vim's diff commands (dp, do, :diffput, and :diffget) to move ...


4

Using git submodules is a common way of doing this. The VimCasts episode is a great explanation, but the basic commands are as below: Adding a new plugin cd ~/.vim git submodule add http://github.com/<username>/<pluginname>.git bundle/<pluginname> git add . git commit Updating a plugin Git submodules are also repositories in their own ...


4

It is strange that the error just appear with git commit -- I guess you have two versions of Vim installed, and the one used by git is older/have less features and thus complain about that option. You could try to configure you git editor passing the full path of the Vim you normally use. In any case, I agree with the comments on your question: you should ...


4

0- +1 to D. Ben Knoble suggestions. Regarding pure vim-scripting 1- Never define autocommands globally. Prefer to define them in their own group, and when filling the group, start by clearing it. This way, the related snippet of code can be re-executed, which you'll will want when you'll be working on your script aug MyGitBranch au! au BufEnter * call ...


3

I would recommend one of the undo tree visualizer plugins: undotree Gundo With them, you can easily revisit previous editing states. You can them (temporarily) restore them (one by one, starting with the oldest relevant), and git commit them, until you arrive back at the original.


Only top voted, non community-wiki answers of a minimum length are eligible