'Unable to load Git Graph' when running via Remote-SSH (with local 'git.path' set, but no remote 'git.path' set)

[Friksel]

[edit]
When using GitGraph via Remote-SSH and there's no "git.path" setting defined both locally and on remote settings.json files, GitGraph uses the default git-path or path-variable on the remote machine, so does exactly what we expect and finds git there.

But when using GitGraph via Remote-SSH when there's no "git.path" setting defined on the remote, GitGraph seem to look for the local "git.path" setting and uses that one instead. But that setting is meant to be used locally, so is a different path to git than the remote git path. Especially when using a different operating system on remote (like Linux) than locally (like Windows).

When needing the local "git.path" variable for our local projects and also need the remote "git.path" variable for remote-ssh sessions, we can override this problem by adding a "git.path" variable to the remote settings.json so GitGraph can alway find git on that remote, but that shouldn't be nececary. And needs to be done for all remotes we are working on, even if we always use the default git installation on those machines.

So it would be best in my opinion if GitGraph always ignores the local "git.path" setting when working in a Remote-SSH session.

BTW Thanks for this great addon!

[mhutchie]

Glad to hear you were able to resolve the issue by fixing your path!

[Friksel]

Glad to hear you were able to resolve the issue by fixing your path!

@mhutchie Thanks for your reaction!

Other addons using git (for example GitLens) and also vs code itself use git without a git.path being set. Also when developing on remote machines via the Remote-SSH addon by MS.

Also Git-graph works locally without a git.path set. But for some reason when developing via SSH-remote the git-path on the remote machine must be set only for GitGraph to work, but doesn't need to be set for the other addons and vs code, because they work fine without it.

Is there maybe a usersetting in GitGraph to use the default git installation on the remote so we don't need to set the git.path on each remote machines user settings.json we work on?

[mhutchie]

If the “git.path” setting is not set, Git Graph defaults to use the Git installation on the remote machine (by checking the path environment variable). For the “Unable to load Git Graph” error to appear, it tried to use it, but it could not be found / executed for some reason on your remote machine.

I’ve tested the extension on all types of Remote Development options, and it has worked for me without having to explicitly set the “git.path” variable. I suspect it is just some configuration difference on your specific remote machine.

There are different ways of running Git commands from an extensions perspective, and even an integration provided through the VSCode API. The method Git Graph uses is common, although other extensions could definitely be using a different method that was not affected on your remote machine.

[Friksel]

@mhutchie Yes, there must be something different between invididual addons and vs code. I just did another test: When I remove the "git.path" setting on the remote user settings.json while working via Remote-SSH GitGraph shows the error again, while I still see GitLens and vs codes repository panel still work. Also when typing git --version inside a vs-code terminal the remote gits version shows that Vs code uses the remote git instead of my local git install on the host machine, so that's all fine.

When using git directly on the virtual machine (with Ubuntu 19.04); inside a Linux terminal git is available in each folder. It's also installed the default way, so no weird install-path or anything.
So for some reason I need to set the git.path on the remote settings.json for GitGraph to work, while everything seem to be setup default and git is accessable from anywhere inside the vm.

[Friksel]

@mhutchie I see the problem now:

When using Remote-SSH GitGraph still seems to be looking at the "git.path" setting inside the local Users settings.json. And that's in my case a different path to git, because the host is running Windows and the remote is running Ubuntu. So it can't find git and because it found a "git.path" setting locally it's not looking for the default installation path on the remote machine.

So it seems to me that GitGraph should never look for "git.path" on the local settings.json when being used with Remote-ssh.

When I temporarely remove the "git.path" setting on my local users settings.json and also have no "git.path" setting on the remote users settings.json everything is working fine with GitGraph. But when I put the local "git.path" setting back in and re-connect SSH to the remote GitGraph throws the error again.

So I think VS Code and GitLens are ignoring the local "git.path" setting and only search for the remote "git.path" setting to use and if that's not set use the remotes' default location or path variable. So that would explain why those work without the "git.path" set on remote settings.json and GitGraph doesn't.

I cannot solve this on my end AFAIK because I need that "git.path" setting on the host machine to use that path for local projects where I don't use Remote-SSH, to use the local git (of Windows in my case).

Or am I missing something here?

[mhutchie]

The Visual Studio Code API acts as an interface for extensions to read the global or workspace settings defined in settings.json. It is not up to the extension to read the settings.json file, VSCode does that. There is also no way of the extension differentiating if the setting came from the local or remote file. (More info here)

You should be able to add "git.path" to the remote workspaces settings.json instead of the shared global settings.json. As the workspace config overrides the global config, you should be able to have your local machines (global config) and remote machines (workspace config) pointing to their respective Git paths.

[Friksel]

@mhutchie Alright, that makes sense.

So if I get it right it's just not possible to leave out the "git-path" on the remote (if we have a "git-path" defined locally), because of the way VS Code settings-hierarchy is build. So we can't leave out the "git.path" on the remote machine when we have a (different) local "git.path" setting defined, because otherwise the wrong path would be used.

So that means we should always define a "git.path" setting on all remotes we're using.

I was hoping for something more general for different remote hosts, because most hosts use the default git locations and/or path variable anyway, so leaving out the path to get the default would be preferred. But I understand it just doesn't work like that now.

So to make the remote path general (and OS independent) still, I just add this to the remotes than, which is still causing the default behaviour of using git from path variable and is working fine:
"git.path": "git"

Thanks again for your help @mhutchie .

[Friksel]

@mhutchie And now that I think of it, there's not even a need to set "git.path" to remote machines anymore if the local machine doesn't have a "git.path" setting defined. So if all machines, both locally as remotes work with a PATH, we never need that "git.path" setting anymore and no matter the OS, all machines just work out of the box if they use their own PATH variable and have the git executable available everywhere.

So I just don't use the "git.path" setting anymore, on no machine. Making everything work just fine on all machines without needing to change settings.jsons other than locally. And it still works when git changes location on whatever remote or locally, if they only have their PATH updated to the new location. So pretty flexible and proof too.

Problem solved.