search

fork-dev / Tracker

Bug and issue tracker for Fork for Mac
511 stars 12 forks source link

Feature: Add non-local repository #929

Open larsnystrom opened 4 years ago

larsnystrom commented 4 years ago

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!

DanPristupov commented 11 months ago

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.

brechtm commented 11 months ago

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).

gr0vity-dev commented 11 months ago

+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.

samskiter commented 10 months ago

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

brechtm commented 10 months ago

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.

brechtm commented 9 months ago

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.

MDcod commented 2 months ago

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.

brechtm commented 2 weeks ago

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

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