GitButler fails silently when attempting to add a repository from a network drive on Windows

[andrew-rosca]

I noticed this on Windows 11 with WSL2. The repository is in the file system of the Linux VM hosted by WSL.

Steps to replicate on Windows:

• add a new local repository
• select the network drive path of the repo (e.g. \\wsl.localhost\Ubuntu\home\butler-repo)

Expected outcome:

• repo is added

Actual outcome:

• nothing happens
• there are no errors in the Tauri DevTools console
• there are no entries in the GitButler log relevant to this operation

[andrew-rosca]

See also #4954

[Byron]

Thanks a lot for letting us know and for the investigation!

It's very strange that nothing happens, I would definitely have expected some action. It's much like the path is rejected between picking it in the modal dialogue and passing it on to the UI. Can this be? CC @ndom91

[ndom91]

There's a special case for trying to open wsl.localhost paths it looks like (see: apps/desktop/src/lib/backend/projects.ts:162). Are you using the windows version of GitButler by chance? If you're planning to use it with projects in WSL2, we recommend installing GitButler in WSL via our linux packages.

[ndom91]

Sidenote: I think Gitbutler is going to have trouble with network mapped locations on linux as they generally don't trigger inotify events. This will have the adverse effect of not showing updated files / hunks in GitButler when you save changes to them.

At least thats the case with normal sshfs or nfs mapped locations, maybe windows / wsl2 does something special here though.

[andrew-rosca]

Yes, using GitButler from Windows.

I've used the Linux version from WSL in the past and it was OK, but window painting is a bit odd at times.

In any case I'm happy to close this issue and suggest updating documentation with this recommendation for users who are on Windows and check out repos in WSL.

Please confirm your recommendation is to close without further action.

[ndom91]

Yes, using GitButler from Windows.

I've used the Linux version from WSL in the past and it was OK, but window painting is a bit odd at times.

In any case I'm happy to close this issue and suggest updating documentation with this recommendation for users who are on Windows and check out repos in WSL.

Please confirm your recommendation is to close without further action.

Yeah that is our recommendation when working with projects in wsl2. I'll make sure that something is added to the docs in regard to this as well 👌

[andrew-rosca]

On further thought--should this be an improvement in the app? The issue is that there's no messaging at all to the user. Displaying something like

Managing repos on network paths is not supported. If you are attempting to manage a repo hosted on WSL from a Windows client, please install the Linux version in WSL instead

would resolve this.

[andrew-rosca]

I see. Well, there's nothing in the logs. I'm looking at

C:\Users\andrew\AppData\Roaming\com.gitbutler.app\logs\GitButler.2024-09-23.log

[ndom91]

@andrew-rosca yeah so that's the correct log file.

I just double checked and it looks like in this showError function from the screenshot above we're only showing a toast message, not logging anything. Therefore, the fact that you're not seeing anything is actually the expected behaviour at the moment. Sorry about the confusion!

Did you also not get the toast error?

[andrew-rosca]

That's correct, no toast error either

[Byron]

That's super interesting insights, thanks for sharing, @ndom91. It will be an interesting thought to which extend GitButler could be made to work even without disk events. First of all, right now I think the UI relies on 'triggering itself' for updates, which is unnecessary as it could know when it should refetch state based on its actions, or its actions could return exactly the state that it would need right after.

Maybe then it would be possible to detect if events are working, and offer a refresh button instead to see worktree updates for example (or simply poll for updates regularly or prior to certain operations).

In any case, being less dependent on filesystem events will be beneficial for the correct functioning and performance of the application.

Regarding this issue, I agree that we should figure out why there was no error message in this case so the rejection is made known to the user.

[ndom91]

Yeah I like the sound of that a lot.

I also, for example, see the file watcher no longer work as expected relatively often when using the appimage on a "normal" Linux system. It always works at first, but then frequently seems to stop responding after a while (30m-60m). I haven't had time to dig into it further, but suffice it to say, there seem to be more than just 1 or 2 edge cases where the current file watcher doesn't behave as expected.

Regarding the error messaging in this wsl specific scenario, I can take care of that today. I'll add logging and see why the toast doesn't appear.

[ndom91]

@Byron as we're in the middle of a bunch of feature work at the moment, this isn't something any of us have time for right now, but I definitely want to take a closer look at this eventually and potentially implement your idea. So I'll create an issue and we can follow-up specifically on the filewatcher improvements there 🙏