GitSavvy doesn't identify git repo in current project folder, sets root to repo several layers up

[akda5id]

This is an odd situation I ran into. Abbreviated folder structure as follows:
~/ (has a .git file pointing to gitdir: ~/Documents/projects/mac_dotfiles/.git)
~/Documents/projects/base_project (this folder has it's own git repo, works fine with GitSavvy, ROOT: ~/Documents/projects/base_project)
~/Documents/projects/mac_dotfiles/ (this folder has it's own git repo, works fine with GitSavvy, ROOT: ~/Documents/projects/mac_dotfiles)
~/Documents/projects/manage_zdisks (this folder also has it's own git repo, but GitSavvy for some reason sees the root as ROOT: ~)

running git status in all of the above folders show what is expected. Why is GitSavvy getting confused? How can I help track down what is going on?
I am doing something a bit strange with the gitdir: in my home, but several other projects created the same way, bog standard git init in the folder work fine, yet this one doesn't. I'm a little suspicious I ran into this issue with the first project alphabetically after mac_dotfiles... but that's all I have to go on at the moment.

[akda5id]

I do think it has to do with the name of the folder somehow:

manage_zdisks % rm -r .git 
manage_zdisks % cd ..
projects % mv manage_zdisks zmanage_zdisks
projects % cd zmanage_zdisks 
zmanage_zdisks % git init
Initialized empty Git repository in /Users/da5id/Documents/projects/zmanage_zdisks/.git/

works fine

zmanage_zdisks % rm -r .git 
zmanage_zdisks % cd ..
projects % mv zmanage_zdisks manage_zdisks 
projects % cd manage_zdisks 
manage_zdisks % git init
Initialized empty Git repository in /Users/da5id/Documents/projects/manage_zdisks/.git/

broken again

To be clear, what is broken is GitSavvy's status page in Sublime Text, git its self in these folders works as expected.

Edit: After some testing of various new folders, it seems to be only this exact folder name that triggers this issue. So I think at some point in my work today, GitSavvy caught that this path was handled by the root repo at ~/ , and doesn't want to let go of that idea. I have poked around a bit, but can't find where GitSavvy might be cacheing this info?

[kaste]

So it seems now you solved it and identified it as a cache miss. That is indeed a problem I never thought about: if an upper directory (like the HOME directory) is a git directory, subdirectories you initialize late may never update. The cache is global and Sublime Text must be restarted. When you have "dev_mode": true, enabled in the GitSavvy settings there is also a command GitSavvy: reload available which clears all caches.

Not having a cache at all is not a good solution so we would need an idea for a good heuristic when to revalidate the cache.

[akda5id]

Huh, I thought I did try a program restart at the end of my testing to see if I could get the cache to clear, and I thought it didn't. But I wasn't being very diligent at that point so I may be mistaken. It is fixed now, so perhaps that is what did it.

I don't have any advice really for how to know when to revalidate the cache, as I think this happened with operations outside of the view of GitSavvy (command line git).

You could traverse the path from what you think is the root to the path of the current file status was being run from, each time status is opened, looking for a closer git dir? That shouldn't be too expensive. Or just a way for the user to trigger such (and some way to learn about it, I found https://github.com/timbrel/GitSavvy/blob/master/docs/debug.md#gitsavvy-reload-modules-debug but was only looking for logging, which wasn't showing anything about cache, I didn't notice the reload option, or think to try it).

Anyway, I posted this issue in an effort to understand what was happening, I don't like "weird things" that I don't grok in my tools/workflow, as from experience it's those edge cases that can bite you hard later. But I think I have a firm enough grasp on it at this point, thanks! And feel free to close.

[kaste]

Validating the cache when opening a special view seems totally reasonable.