cc @Vinzent03 @reinaldoarrosi

What was the exact issue you were experiencing? Reading the documentation it should be enough to launch the git process from the vault base path which is the case currently:

Set the path to the repository (".git" directory). This can also be controlled by setting the GIT_DIR environment variable. It can be an absolute path or relative path to current working directory.

Specifying the location of the ".git" directory using this option (or GIT_DIR environment variable) turns off the repository discovery that tries to find a directory with ".git" subdirectory (which is how the repository and the top-level of the working tree are discovered), and tells Git that you are at the top level of the working tree. If you are not at the top-level directory of the working tree, you should tell Git where the top-level of the working tree is, with the --work-tree= option (or GIT_WORK_TREE environment variable)

If you just want to run git as if it was started in then use git -C .

The issue I was having was that I have my Git repository outside of the obsidian vault path, and no configuration options would get the plugin to work with that scenario.

My vault is "/Users/jstillwell/Documents/Obsidian Vault"
my bare git repo is "/Users/jstillwell/Documents/obsidian.git"

I have the custom git path set.

But that alone didn't work.

And no settings for "Additional Environment Variables" helped either. GIT_DIR and/or GIT_WORK_TREE.

I'd always get

But applying this one line patch fixes everything. Now I don't even need the environment variables either. Just the custom git path.

Does that explain it?

Hmm it works perfectly fine for me without that setting. Which git version are you running? (git --version)

I could finally reproduce the case. So far, I only tested it by moving the .git directory, but that is not a real bare git repo. So by making it bare, the work tree env var is needed. Thanks for fixing it!

Yeah, it's a weird pattern, I know. Using a bare repo lets you keep your git work tree completely separate from the git files. Useful if you have some tooling that works with the directory, and you don't want that fooling with the repo/git history. Or if you’re serving those files up, say, via a web server, and you don't want people to access the history either.

Thanks for the merge.

Also, I didn't know that a .git dir wasn't also a bare repo. That's new. I looked into it, and yeah, the repos save whether they were created as --bare or not. Interesting.