Open shippy opened 7 years ago
Got it! It's the $GIT_DIR
environment value set by the git hook! Debugger output (stepping through the call initiated by the git hook):
# vim debugger
>echo $GIT_DIR
/private/tmp/bugtest/.git/modules/dotvim
Shell output:
# shell
% pwd
/private/tmp/bugtest/dotvim/bundle/Vundle.vim
% git rev-parse --show-toplevel
/private/tmp/bugtest/dotvim/bundle/Vundle.vim
% echo $GIT_DIR
% GIT_DIR=/tmp/bugtest/.git/modules/dotvim git rev-parse --show-toplevel
/private/tmp/bugtest/dotvim
GIT_DIR
sets the working directory, as far as git is concerned, so that git commands will know what repo to operate on even if pwd
is different. That's why the command goes awry. The upside is that there's an easy fix: env -u GIT_DIR
or unset GIT_DIR
will take GIT_DIR
out of the environment for one command:
# vim debugger
>echo system('cd ''/Users/sp576/.vim/bundle/Vundle.vim'' && env -u GIT_DIR git rev-pars
e --show-toplevel')
/private/tmp/bugtest/dotvim/bundle/Vundle.vim
>echo $GIT_DIR
/private/tmp/bugtest/.git/modules/dotvim
>echo system('unset GIT_DIR; cd ''/Users/sp576/.vim/bundle/Vundle.vim'' && git rev-pars
e --show-toplevel')
/private/tmp/bugtest/dotvim/bundle/Vundle.vim
>echo $GIT_DIR
/private/tmp/bugtest/.git/modules/dotvim
>echo system('echo $GIT_DIR')
/private/tmp/bugtest/.git/modules/dotvim
I don't foresee any circumstance under which Vundle would need to know what $GIT_DIR
says, so I'll file a PR that prefaces all relevant commands with unset GIT_DIR;
.
I recognize that this is the edgiest of edge cases (and also a case of shooting myself in the foot), but bear with me. (Edit: I started filing this issue while debugging, and now I'm not so sure this is a bug in Vundle; filing nonetheless.)
I started version-controlling my vim dotfiles before all other dotfiles. This has led to a somewhat idiosyncratic setup:
Vundle
is a submodule ofdotvim
, which is in turn a submodule ofdotfiles
. Consequently, it lives in~/dotfiles/.git/modules/dotvim/modules/bundle
.Description of the problem:
Recently, I wanted to automate the plugin update / cleanup after every git pull, so I created a
post-checkout
git hook for thedotvim
repo. Sincedotvim
is itself a submodule, the hook lives to~/dotfiles/.git/modules/dotvim/hooks/post-checkout
rather than~/.vim/.git/hooks
. The hook is simple:...which results in Vundle properly updating the plugins, but also changing the remote and updating the contents of my
dotvim
submodule rather than of the plugins indotvim/bundle
. (You can watch it happen live withcd ~/.vim && watch -n 1 "git remote -v"
.) Theorigin
URL ofdotvim
ends up pointing at the remote of the last plugin that Vundle touched when the hook finishes.Conditions:
This only happens in the git hook for submodule-of-a-submodule situation. It doesn't happen when:
exec vim -c VundleUpdate -c PluginClean! -c quitall &> /dev/null
is invoked from the command line,dotvim
is cloned directly into~/.vim
, Vundle is its submodule, and the very same git hook sits in~/.vim/.git/hooks/post-checkout
, orPlugin 'VundleVim/Vundle.vim'
fromvimrc
.Debugging:
(You can replicate my setup by running this gist.)
When I change the command to
exec vim -c VundleUpdate -c PluginClean!
and access the log, it starts with:The weird thing is, I stepped through the debugger and all those commands make sense! This is the command right before it's run through
system
ins:system
:I tried running it from the command line; it did the expected thing. At first, I thought that what seems to be happening is that
system
isn't processing the directory change command (for whatever godforsaken reason), but no:Rather, it seems that it's something about vim calling git that's going screwy:
...compared with the direct shell call:
I'm stumped as to what it is, though. A quick check says that both calls invoke the same git executable and share the same path; I'll dig further.