search

tpope / vim-fugitive

fugitive.vim: A Git wrapper so awesome, it should be illegal
https://www.vim.org/scripts/script.php?script_id=2975
20.01k stars 1.01k forks source link

:Gcommit incompatible with 'set autochdir' #1195

Closed ChrisPenner closed 5 years ago

ChrisPenner commented 5 years ago

When I open :Gstatus and run :Gcommit I get:

fugitive: fatal: This operation must be run in a work tree

My :pwd in the :Gstatus window shows that I'm inside the project-root/.git directory, so it makes sense why it's failing, I suspect this is due to the fact that I have set autochdir in my vim config.

Unfortunately this isn't so easy to fix, I tried a simple lcd ../ in a BufEnter autocmd, but it seems that the autochdir happens AFTER that, I'm not aware of any autocmd triggers that happen after that.

Have any ideas? Perhaps :Gcommit could be run from the git root instead of pwd? If there's anything I can change in my config I'm happy to.

Thanks for the great plugins!

tpope commented 5 years ago

It does force the Git root, and it's working fine for me even with 'autochdir'. Methinks you have something else nefarious in your config.

ChrisPenner commented 5 years ago

Interesting! I'll take another look

ptrin commented 5 years ago

I also have this issue. It seems that in the :Gstatus buffer my working directory is .git. Running :cd .. made :Gcommit work again.

tpope commented 5 years ago

Is this a new issue, or has the :Gstatus overhaul merely drawn your attention to it?

ptrin commented 5 years ago

I think it's probably a new issue. If it helps to debug, my vimrc is here: https://github.com/ptrin/vimconfig/blob/master/vimrc

tpope commented 5 years ago

Try on version 2.5, please, "probably" isn't very helpful.

ChrisPenner commented 5 years ago

I tried a few versions going backwards, it seems to exist on 2.5, 2.2, 2.0 and even 1.0. I know that this has worked for me in the past, which suggests to me that perhaps instead of being a new problem in fugitive it could be caused by a change or update to neovim? (BTW I use nvim v0.3.4)

tpope commented 5 years ago

Sounds like a plausible hypothesis.

ptrin commented 5 years ago

I don't think it's related to neovim because I don't use it but still have the issue. For now I've disabled autochdir.

ltgouvea commented 5 years ago

I started experiencing this issue when I updated/recompiled my vim 8 so I could install coc.nvim. Disabling autochdir made everything work normally again.

tpope commented 5 years ago

Has anyone tried reproducing the issue with other plugins disabled and a minimal vimrc?

If you edit a file, :cd to a different directory, and call :!pwd, does it report the new directory or the parent directory of the file?

ltgouvea commented 5 years ago

I can try that scenario, @tpope, how specific the vimrc should be?

tpope commented 5 years ago

:set autochdir plus whatever you need to get it to load Fugitive.

That second question can also be answered outside of the minimal vimrc context.

ltgouvea commented 5 years ago

I successfully reproduced the issue using only :autochdir + Fugitive installed. When i used :cd the directory reported was the new directory.

tpope commented 5 years ago

Here's the relevant code. It looks complicated but most of it is just building the argument string. The s:Cd() call changes to the working directory to the work tree. I guess my recommendation would be to throw a bunch of :pwds in there and see if the working directory is correct.

https://github.com/tpope/vim-fugitive/blob/41a734ef49c78cfdb97426cda811ee99c39e011a/autoload/fugitive.vim#L2665-L2690

tpope commented 5 years ago

We now use git -C <worktree>, so this issue should be moot.

sim590 commented 5 years ago

I still experience this issue while using version 5eeb7625df75a0da931d81a84e8730aca8b8c8a1 (2019-10-01). The value of pwd is .git in :Gstatus window and my work tree when in my work buffers. I do use autochdir option.

tpope commented 5 years ago

Add :echo command before this line and see what it's trying to run: https://github.com/tpope/vim-fugitive/blob/80aa8a9aea72f2054fb2ad8582461f60b0db9757/autoload/fugitive.vim#L3298

sim590 commented 5 years ago

@tpope I had to put :echoerr instead to see the message. Otherwise, the message would not show up. I get this:

env GIT_EDITOR=false git commit
tpope commented 5 years ago

That command is generated by s:UserCommand() a few lines above, which in turn is a thin wrapper around s:UserCommandList(), which does the following:

https://github.com/tpope/vim-fugitive/blob/698065596c9ccee74825ac9667357ce8222ed7b0/autoload/fugitive.vim#L245-L247

In English, this is "if there is a non-empty work tree (not a bare repository), and that work tree is not the current directory, add a -C argument". So this should trigger if the working directory is .git as you suggest.

You can try adding echoerr tree . ',' . getcwd() there and see if that matches your expectations.

sim590 commented 5 years ago

@tpope the output of tree is the root of the working tree, but pwd is $ROOT/.git. Therefore, there's something wrong because I still get fatal: this operation must be run in a work tree error message.

sim590 commented 5 years ago

I have just found out something useful: opening the file directly using vim myfile, then I don't have the bug. If I open only with command vim and select the file using :Startify (from startify plugin buffer), then I get the bug! I'm sorry that I didn't try without disabling everything. I know that I made you work may be for nothing. But is that useful information? Could vim-fugitive try to protect against whatever is causing this? Otherwise, may be there's something I could report to Startify upstream?

tpope commented 5 years ago

@tpope the output of tree is the root of the working tree, but pwd is $ROOT/.git. Therefore, there's something wrong because I still get fatal: this operation must be run in a work tree error message.

So I guess try adding an echoerr inside that elseif to see if it triggers. And then check the value of git, etc. Something isn't adding up.

I have just found out something useful: opening the file directly using vim myfile, then I don't have the bug. If I open only with command vim and select the file using :Startify (from startify plugin buffer), then I get the bug! I'm sorry that I didn't try without disabling everything. I know that I made you work may be for nothing. But is that useful information? Could vim-fugitive try to protect against whatever is causing this? Otherwise, may be there's something I could report to Startify upstream?

Fugitive could possibly guard against something, but it's on you to find what that something is. Little harm in opening a Startify issue, but 'autochdir' is a cross you choose to bear, it's still probably going to have to be you that finds the problem.

sim590 commented 5 years ago

Actually, Startify may have little to do with this. I still get the bug for some reason after some manipulation that I don't recall (but without using Startify). I fixed by issuing :cd . ... :/

Anyway, when opening with Startify while echoerr is placed in the elseif you mentioned, there's no output, so it's not called. I tried with Startify because it seems that I can trigger the bug like this. As mentioned in my last paragraph, I still can trigger the bug randomly without, but I'm not sure how.

EDIT: As I said above, I can fix the issue with :cd . (not .., but really .). Then, even if pwd is .git, it works since it's using the -C option.

sim590 commented 4 years ago

I think that the real responsible of the issue was Ctrlp back when I was using it. Now, it is caused by Fzf as I have documented here:

https://github.com/junegunn/fzf.vim/issues/993