Error when switching to eclim ProjectTree #234

rnestler opened this Issue Aug 6, 2012 · 8 comments


None yet
5 participants

rnestler commented Aug 6, 2012

I use the [eclim] plugin. When I switch to the ProjectTree split window (with ^-w,^-w) fugitive throws the following error:

Error detected while processing function <SNR>26_Detect..fugitive#buffer..<SNR>26_buffer..<SNR>26_throw:
line    2:
E605: Exception not caught: fugitive: not a git repository: workspace/project/ProjectTree_1

The project directory is actually a git repository, but the ProjectTree_1 file/folder doesn't really exist

exic commented Sep 28, 2012



tpope commented Sep 29, 2012

Can you give me a simple way to reproduce this without installing Eclipse and Eclim?

exic commented Oct 4, 2012

I don't know what kind of file properties :ProjectTree actually sets (so I have no idea how this would be reproducable), but I noticed that I don't get the error if the projectroot directory (with Eclipse's .project file) is the same as the directory that has the .git directory. Is there something like the unix "env" command for vim buffers? If so, I could have a look what is the difference between the two setups.

I worked around this problem in my clone catching the exception and returning from the Detect function (

I get this problem too.

Anyone who is using a combination of Vim + Eclim + Eclipse, and has used the Egit plugin for Eclipse, is likely to have their git repo files a directory level higher than the root directory of a particular Eclipse project monitored by git.
That is, if they have followed the advice supplied by the Egit user guide:



tpope commented Nov 28, 2012

I don't think that's really relevant here. Here's the basic idea of s:Detect.

  1. Try to find .git by walking the directory hierarchy.
  2. If it's found, save it in b:git_dir.
  3. If b:git_dir exists, set up fugitive

The error you guys are reporting is that b:git_dir doesn't exist in 3. Which doesn't make sense at all.

Thanks for the response Tim. I happily admit minimal familiarity of the background code here. :-)
I simply have noticed the same problem and recalled the potentially unusual recommendations from the Egit guide.

While I'm on - I unfortunately have windows inflicted on me at work - I noticed that the fugitive documentation doesn't mention that for Win systems you will need to add the Git binaries to the PATH env var so that fugitive can find them. Fairly obvious I know, but just my 2 penneth of grease for the coggage.

I will test the (Vim + fugitive + Eclim + Eclipse) glitch on my Debian system when I get a few moment to see if the same problem exists there, or if it's just a Win thing ...


Looking into this further - I think it's Eclim's creation of the (non existent) "ProjectTree_1" object that fugitive doesn't like. This object certainly doesn't exist in the filesystem but Eclim has fooled Vim into believing it does ...
I shall bug Eclim devs about this.

@ervandew ervandew added a commit to ervandew/eclim that referenced this issue Dec 1, 2012

@ervandew ervandew fix :ProjectTree use of fugitive for diplaying branch info
the ProjectTree has a User autocmd to trigger the tree's vcs info, which
will then trigger a fugitive autocmd, which will trigger a User autocmd,
which then inadvertently triggers the ProjectTree User autocmd, and so
on until vim says enough is enough. Fix this by preventing the
ProjectTree autocmd from being executed recursively.

fixes tpope/vim-fugitive#234

ervandew commented Dec 1, 2012

This issue was brought to my attention today and after taking a look I came up
with the steps to reproduce, the cause, and a fix on the eclim side.

@geebotron made an accurate observation that the problem only occurs when the
git repo is one directory higher than the project. I didn't take the time to
figure out why that's the case, but that was the only condition I could come up
with that would trigger the error.

Oddly enough, the error that is raised in this condition:

E605: Exception not caught: fugitive: not a git repository: workspace/project/ProjectTree_1

is a red herring. Both eclim and fugitive make use of silent when triggering
autocmds (to suppress annoying "no autocmd found" type output from vim), but by
doing so they masked the true cause of the error. Eclim's ProjectTree has a User
autocmd which triggers an info function to add/update vcs information in the
tree buffer. It attempts to use ervandew/vcs, but if not available will fallback
to using fugitive by triggering its BufReadPost autocmd. Unfortunately that
autocmd will trigger a User autocmd of its own which will inadvertently trigger
ProjectTree's autocmd again, and so the cycle continues until vim puts a stop to
the madness and control returns to fugitive which then raises an error because
no git repo could be detected by that mess.

Ultimately I place the blame on eclim, because its User autocmd apparently needs
to have a pattern more specific than just <buffer> to prevent other plugins
from triggering it. Rather than change that though, since I'm not sure what
usage cases that may adversely affect, I simply added a guard to prevent it from
being executed recursively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment