Feature: Add non-local repository

I work a lot on code that lives on a different machine than the one I'm sitting at. I'm accessing the code over SSH.

At the moment, Fork can only open repositories that live on your current computer. I could possibly use sshfs to mount the remote host locally and then open it in fork, but this is pretty complicated on MacOS because it requires me to install osxfuse (which is closed source and tends to break for every new MacOS release) and sshfs and make sure that the mount point keeps working.

The work-around I'm using right now is to clone the code to my local computer and then add the remote host as a remote in my local repository. Then I can cmd+shift+f to fetch the latest changes in Fork.

But it would be so much easier if I could just add a new repository in fork using a normal url like me@some-machine:projects/my-project. Sometimes that remote repository may be a bare repository, but it will always be something that git remote add would accept.

Fork is such an amazing application and this feature would let me explore repositories on various hosts without having to clone them first.

Thank you!

The work-around I'm using right now is to clone the code to my local computer and then add the remote host as a remote in my local repository. Then I can cmd+shift+f to fetch the latest changes in Fork.

I think this is the correct solution there.

Yes, but there are two things that could be improved in that workflow:

It would be handy if I could give Fork a URL and it would clone the repository for me (to some random location somewhere on my computer, the point here is that I should only have to provide a URL and then the repository would open in Fork).
When looking at the the repo in Fork, "Branches" should list the branches of origin and "Remotes" and "Stashes" should be hidden. Basically, I want to see the repository as if I was on the origin machine (the one I cloned the repo from).

When looking at the the repo in Fork, "Branches" should list the branches of origin and "Remotes" and "Stashes" should be hidden.

The point is that this workflow is very rare. We don't have much resources for implementing and, more importantly, maintain the code for this feature in the future. I'd rather keep the Fork source code simple.

That's totally understandable. It was an idea I had to simplify the workflow I'm using every day so I thought I'd share it. But I understand it's not possible to implement all the things.

Feel free to close this issue if you decide not to pursue this particular feature. And thank you for Fork! I'll go buy a license now, because I'm using Fork every day for my work.

I think there is a sea change in development going on right now that might merit taking a second look at this feature. Namely: almost everybody I know seems to be switching from local development to developing remotely using something like this:

https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

The idea of "cloud IDE in the browser" hasn't really panned out for most workloads, but this VS Code feature (and similar ones coming out for other editor/IDEs) let you keep the source code in the cloud, you build and run in the cloud, but do your programming locally on your Mac with a reasonable editor and good performance. This is becoming popular, I think, because you can set up the dev env once, and then just sit down at any machine with VS Code installed and do the programming part. You don't need to set up your client machine with all the dependencies, and you can have the cloud machine be as beefy and powerful as you need it to be.

What I am seeing my team — and me too — do in this environment is to stop using our favorite Git clients (mine is Fork, some co-workers use Tower or whatever), and just go back to relying on command-line git, and and maybe the VS Code git UI.

We all use GUI git apps to make our lives more convenient. There's a free, functional command line available in which we can do everything we need to do, it is just nicer and faster to do it using a nice GUI. So while I do indeed use Fork any time I am developing something locally, I find myself doing that less and less — and so I am using Fork less and less.

Cloning a remote repo to my Mac, waiting for that to finish, then opening it and navigating to the file I am interested in and then finally viewing the diff or whatever in Fork — it is nicer in the end result than looking at it on the command line or in VS Code's slightly weird git thing, but it takes way longer and so I don't do it.

I think eventually the ability to open a remote git working copy via SSH will probably become a table-stakes feature for GUI git clients. I guess today Fork does do a lot of direct local filesystem I/O, but theoretically it could all be done via SSH instead, for "SSH remote working copies".

Will probably be a required feature in the future and indeed would be immediately useful to many of us today.

@masonmark

@masonmark Well put. I’m also using VSCode SSH remote extension. It works like magic. Right now I’m keeping local copies of the repos only to look at them with Fork.

I have mounted the remote using sshfs to use Fork, but it’s painfully slow. (My use case is with a VM hosted locally, so I also tried SMB; it’s similarly slow.)

@Noleli

@Noleli
I myself use Parallels VM and the performance between parent (macOS) and child (Windows) is almost the same as the native performance.

My sharing settings are pretty standard:

@DanPristupov

Thanks, @DanPristupov. VirtualBox only lets you share a folder on the host to the guest. The mounted volume on the Linux guest doesn’t seem to support symlinks, named pipes, or other special file types and permissions. So I’m stuck with trying to find a way to make the guest filesystem available to the host.

@DanPristupov

I have mounted the remote using sshfs to use Fork, but it’s painfully slow. (My use case is with a VM hosted locally, so I also tried SMB; it’s similarly slow.)

I had the same experience (although I was using rclone instead of sshfs for the mount). Looking for a solution, I discovered sshfsexec, which I thought should be able to provide a solution for SSH similar to wslgit for Fork and WSL (fork-dev/TrackerWin#305) which I have been using succesfully for months. This did require some additional work to for Fork to be able to open a remote SSH repository, but nothing too outrageous. It turns out it's not even necessary to mount the remote directory as Fork seems to rely mostly on git calls to interact with the repository. It suffices to create an empty directory on your machine and provide a corresponding mapping in sshfsexec. I did notice that the list of stashes is missing, so I suspect Fork does access files in the .git directory directly for this. Another quirk is that Fork seems to loose track of which commit is currently checked out under certain conditions.

While not as fast as accessing a local repository, browsing the commit history seems to be fast enough to be practically useable. Committing is not working yet as the commit message file needs to forwarded to the remote, but that shouldn't be difficult to manage.

Interactive rebase is however a more complicated story, because of the interaction with fork_ri. I embarked on a small adventure trying to forward the editor calls on the remote server back to fork_ri on the host. This works well for the git-rebase-todo file, but for some reason fork_ri does not write changes to the COMMIT_EDITMSG file when rewording a commit. @DanPristupov Perhaps you have an idea what I'm overlooking here? Any idea why this works for git-rebase-todo but not for COMMIT_EDITMSG. Thanks!

@brechtm

@brechtm fork_ri reports errors to the IR output. Do you see any error dialog when the problem occurs?

Regarding what's going on in fork_ri. The tool is called with a path argument which is normally /.git/COMMIT_EDITMSG. Here's is the simplified source code:

            var outputTodoPath = args[0];
            var messageArchivePath = outputTodoPath; // /.git/COMMIT_EDITMSG
            messageArchivePath = Path.GetDirectoryName(messageArchivePath); // /.git/
            messageArchivePath = Path.Combine(messageArchivePath, "rebase-merge"); // /.git/rebase-merge
            messageArchivePath = Path.Combine(messageArchivePath, "fork-message-archive"); // /.git/rebase-merge/fork-message-archive
...
            var message = ReadMessage(messageArchivePath);
...
            File.WriteAllText(outputTodoPath, message);

fork_ri reports errors to the IR output. Do you see any error dialog when the problem occurs?

No, I didn't see any error. However, I was not aware of the role of fork-message-archive. git-rebase-todo and COMMIT_EDITMSG were copied over from the remote to a tmp directory on the host (so, there was no rebase-merge directory).

I now recreated the .git structure (just the .git/rebase-merge/git-rebase-todo and .git/COMMIT_EDITMSG) in the temporary directory and I see that the fork-message-archive (containing the new commit message) file is being created in the rebase-merge directory. Alas, the new message is still not being written to COMMIT_EDITMSG.

Is there any other data being passed between Fork and fork_ri that might be getting lost? Perhaps through environment variables or interprocess messaging? Does fork_ri read any other files besides the ones mentioned here?

Somewhere along the debugging path I saw an error mentioning .git/rebase-merge/done. Is that file also processed by fork_ri, and at what point?

Many thanks for the pointers!

I guess, the reason is simple. File.WriteAllText(outputTodoPath, message); accesses the file system. Most likely it's the same problem as the one with stashes and HEAD which you mentioned before. How does the absolute path looks in your case?

I guess, the reason is simple. File.WriteAllText(outputTodoPath, message); accesses the file system. Most likely it's the same problem as the one with stashes and HEAD which you mentioned before. How does the absolute path looks in your case?

That shouldn't be the issue here. I start a second process on the host that downloads (scp) git-rebase-todo and COMMIT_EDITMSG (after git creates them), calls fork_ri on them and uploads them. But fork_ri doesn't write the new commit message to COMMIT_EDITMSG, even though that works fine for git-rebase-todo.

Some other things I tried, without success:

downloading the files to the usual location (in the checkout dir's .git folder)
with the remote files mounted locally (not using sshfs but rclone which I happen to have installed)

In the latter case, Fork has access to all files, so it should work if no data is being passed in another way. But perhaps there is some caching going on that breaks things.

Actually, the stashes don't show up even when the remote files are mounted locally, so I'm not sure what the reason is.

Actually, the stashes don't show up even when the remote files are mounted locally, so I'm not sure what the reason is.

Did you check the log file %localappdata%\fork\logs\fork.log? It may contain some info.

@brechtm

@brechtm Fork also reads (using mmap) the objects (both .pack and .idx files) in the .git/object folder.

I'm sure there are good reasons to do this, but I'm wondering what they are. Do you plan removing the git dependency completely eventually?

You can imagine I'm a bit sad that these kinds of changes will eventually make it impossible to use Fork remotely. Losing the ability to inspect/apply stashes is already enough of a handicap for me to roll back to 2.31.2. Of course, I realize that using Fork on remote checkouts is a very niche use case, so I understand it's not a priority to support it in any way.

I love fork, but my development environment is a separate linux box that I shell into via vs code. Would love to be able to use fork on my all of my repo's remotely....

@brechtm

Thanks. Can you give a hint as to what changed? That can be a real time-saver 😄

Now Fork reads stashes directly from the repo. I think it will be difficult to handle in your case.

For stash operations, does Fork only access .git/logs/refs/stash or also other files? I see Fork is also accessing objects (pack files) after reading the former. If Fork only reads .git/logs/refs/stash, implementing support for it in forkgit might still be feasible.

Just wanted to say a big thanks to brechtm for creating forkgit - it's really made a bunch of situations easier for me....

I still think there's a place for trying to get forkgit or Fork itself to with VSCode repos so forkgit can piggy back of the connection VSCode makes...

I have found the limitations of forkgit quite quickly though with my Raspberry Pi development environmnent - e.g. I don't seem to be able to browse changes in the tree. I presume this is related to the conversation between @brechtm and @DanPristupov above. If it helps, I'm happy to contribute (a little) time or sponsor the project to get the updates in place to get forkgit working seamlessly again with remote repos. @DanPristupov VSCode has made remote dev so much easier these days but I still have a strong preference for good GUI-based tools for coding and managing SCM...

Do we know which files fork needs access to to mmap over and why yet?

I don't really know too much about mmap but could sshfsexec be tweaked to allow mmap to occur over a remote. If so then all that would be needed is for fork to allow us to configure the 'mmap' binary (as we can the git binary)....

Do we know which files fork needs access to to mmap over and why yet?

The majority of files in .git/. Some are mmaped (e.g. objects/), some are simply read into memory (e.g. rebase-apply/). Why? Because that's how Fork gets the data.

Do we know which files fork needs access to to mmap over and why yet?

I don't really know too much about mmap but could sshfsexec be tweaked to allow mmap to occur over a remote. If so then all that would be needed is for fork to allow us to configure the 'mmap' binary (as we can the git binary)....

mmap is not a command line tool like git but a function provided by the OS, so it cannot be wrapped by sshfsexec.

Personally, I have copied version Fork 2.31.2 to Fork-2.31.2.app, and use that for interacting with remote repositories. Using both this old version and the current one causes some annoyances however, since these share the same application data (e.g. the set of repositories opened on application start).

+1 for native support to handle remote ssh repositories.
Love Fork, but now mostly work on a codebase via VS Code remote-SSH.
Tried mounting the remote folder with Fuse and sshfs but it's too slow to be usable.

By the looks of it, there's 10-20 of us who really would love better, more official support for remote repos AND we're kinda close to something smooth with forkgit - just some of the diff views, rebasing and such don't work great.

Hell, I'd be happy with just a VSCode integration to fork (click a button in VSCode and fork fires up with full access ot the repo I am working on). Gitkraken doesn't just doesn't cut it for me - it's really hard to do hunk-wise staging. I really don't like managing git inside my IDE - I'm super happy to switch to a totally different view/app to do that work.

This could be THE PREMIER tool for managing git through VSCode, where more and more people are working with remote repositories (and potentially bring more users and revenue to Fork).

Now, personally I'm prepared to chip in some dosh to fund Dan and Tanya working to get this officially supported if they would be keen (?) - is anyone else? If so, let's get a show of emojis?

👀 - You have my support up but sorry, no money
👍 - YES I'd contribute $1 - $5 to help make this happen
❤️ - Count me in for $5-$10 !
🎉 - Are you kidding? $10-$50 would be well worth it
🚀 - I WOULD PAY ANYTHING (well not anything) $50+ is a no brainer

@DanPristupov

A relatively low-effort approach to provide some support for remote repositories is to release a (unsupported) version of Fork 2.31.2 that uses a different application data directory than the current Fork version. This way, people could use that version for remote checkouts and the current version for local checkouts. Is that something you would consider, @DanPristupov?

This would provide a stable target for forkgit to work with, as recent changes make it more difficult for forkgit by accessing git files directly. I might even get interactive rebase working for it.

I added instructions to forkgit's README on how to create a "RemoteFork" application bundle that stores its settings in a location separate from where regular Fork does. This makes it more comfortable to use RemoteFork (2.31.2) and a recent version of Fork alongside each-other.

Oh my god, that would be a really awesome opportunity. Our team of 50 people is completely switching to remote development. That is, in fact, the computer on which I press buttons acts as a thin client. And all the main work is done on a powerful virtual machine in the cloud. And now we have to use git graph in vs code and compared to Fork it is disgusting.

The experimental windows branch of forkgit implements support for the Windows version of Fork. Basic pointers:

for now, you'll need to build git.exe yourself
- check out the windows branch
- install pyinstaller and run devel_exe.ps1 in a PowerShell terminal
downgrade to Fork 1.86
- immediately disable auto-updates in the settings
- perhaps it's possible to install it alongside the current version for Fork somehow, but I haven't looked into that
follow instructions in the README
- additionally, create an empty .git/config file locally for remote repositories to pacify Fork

Barely tested! See brechtm/forkgit#7 for details.

And now we have to use git graph in vs code and compared to Fork it is disgusting.

I totally agree.

The point is that this workflow is very rare. We don't have much resources for implementing and, more importantly, maintain the code for this feature in the future. I'd rather keep the Fork source code simple.

I totally get it.

But I'm adding my +1 to this, in case it should become relevant in the future.

Any news on this? Is it already possible?

I also believe this is becoming a more and more important feature with agents. I have agents runnning on remote machines all the time, and Fork is the main place where I'd like to review, stage, commit their work.

Navigation Menu

Repository navigation

Feature: Add non-local repository #929

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature: Add non-local repository #929

Description

Activity

DanPristupov commented on Mar 9, 2020

larsnystrom commented on Mar 10, 2020

DanPristupov commented on Mar 10, 2020

larsnystrom commented on Mar 10, 2020

masonmark commented on Jun 15, 2020

larsnystrom commented on Jun 15, 2020

Noleli commented on Jun 2, 2021

DanPristupov commented on Jun 2, 2021

Noleli commented on Jun 3, 2021

brechtm commented on Dec 6, 2021

DanPristupov commented on Dec 6, 2021

brechtm commented on Dec 6, 2021

DanPristupov commented on Dec 6, 2021

brechtm commented on Dec 6, 2021

DanPristupov commented on Dec 6, 2021

33 remaining items

brechtm commented on Aug 29, 2023

jonasflint commented on Sep 18, 2023

samskiter commented on Nov 18, 2023

samskiter commented on Nov 24, 2023

DanPristupov commented on Nov 24, 2023

brechtm commented on Nov 24, 2023

gr0vity-dev commented on Dec 11, 2023

samskiter commented on Jan 1, 2024

brechtm commented on Jan 2, 2024

brechtm commented on Feb 8, 2024

MilkovD commented on Aug 23, 2024

brechtm commented on Oct 21, 2024

HackingSMA commented on Jul 29, 2025

wlandgraf commented on Jun 22, 2026

coorasse commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions