Remote SSH Connect

This would be enormously helpful to me, and to many other remote workers. The central office has the powerful server, but I'm quite a few milliseconds of latency away. I've tried file sharing, but it's super-duper-doggy-slow. Having (most of) the processing done on the remote machine would really speed things up.

Please describe more detailed what exactly should be provided in SmartGit. Making remote repositories directly accessible without a local clone would be something which we'd consider low priority. But maybe external tools could already help to execute some ssh command that performs some remote command on the server.

Remote machines always support ssh, but almost never file sharing. Even if sshfs is used, the latency to the server makes file sharing far too slow for the disk-access-heavy actions that git and SmartGit use. This means that we must go back to caveman days and use command-line git to manipulate files on the remote machine.

Yes, I could use a local clone, but the remote machine is a monster Linux compile engine with the cross-platform development tools I need. It's also proximal to the hardware I'm developing for. I'd have to commit and check out every time I wanted to compile. Note also that I'm compiling the Linux kernel, which can only be done on a case-sensitive file system, and macOS and Windows are case-insensitive. (Separate gripe: tens of thousands of source files, and somehow it's important to have those twelve pairs of files whose names differ only by case? Grrrrr...)

I don't know SmartGit's internals, but it seems to do a lot of its intensive file access by directly calling the git tool. The obvious thought is to have SmartGit reach across the network and call git on the remote machine, thus drastically cutting back on the network traffic required. This ignores when SmartGit directly accesses the file system, but perhaps that's well-capsulated and so could be easily redirected across ssh.

(I understand about the low priority, but we can dream, can't we?)

I don't know SmartGit's internals, but it seems to do a lot of its

intensive file access by directly calling the git tool.

Ah, such is life...

Just like the Visual Studio Code remote development mode.

Split SmartGit into a server and a GUI client. All operations are performed on the server. And a GUI client can choose to connect to a local/remote server. That'll do it.

Indeed, that's exactly the feature what I'm looking for.

In fact, I'm currently using VSCode remote extension + GitLens extension to operate on my distant repo using SSH but I don't like having two different workflow. SmartGit is better for branch management.

A "VSCode remote extension" like feature would be great with:
- Auto install and update server when connecting over ssh

-- If distant server is able to connect to Internet then use its own connection for server install/update

-- If distant server is no connected to internet then use our (client) connection for server install/update

For those who are not using VSCode and its remote extension, could you please describe exactly what you expect SmartGit to do?

"Expect" is too strong a word, but I would like SmartGit to be able to work relatively quickly over an ssh connection, perhaps by using a tool of some sort installed on the remote machine.

Do you mean SmartGit should operate on the remote working copy or should SmartGit only be able to pull there all locally committed/pushed commits from the central repository? The first would mean to rewrite SmartGit from the ground.

The dream would be the latter, and I understand completely.

The main purpose of this RFE is to be able to use SmartGit on an headless server without XServer/ VNC/ Nomachine/ etc.

About VSCode remote extension, you can take look on official docs:

https://code.visualstudio.com/docs/remote/ssh

https://code.visualstudio.com/docs/remote/ssh-tutorial

Quickly, when connected to a ssh server, VSCode becomes an UI and all its command and process (file open, edit, save, parsing, analysis, searching) are done directly on the server using an headless executable (vscode-server) so it is really fast, almost no latency between the UI and the server.

For SmartGit, it would imply having a SmartGit UI process on the client machine and another SmartGit headless process that would communicate with the UI process through SSH.

Another way could be that SmartGit is just an headless process providing access to its UI through an internal Webserver but a native UI is still better for me.

This would mean to rewrite SmartGit from ground. Unlikely to happen.

I am the original poster of the comment from four years ago. Surprised this is getting traction, but I guess that is how the world works.

For the record, I have been a long time SmartGit user and use the product almost daily.  It is my opinion that SmartGit has the best UI in terms of reflecting the terminology and workflow of the git system, as opposed to some of your competitors. In that regard, I do use VS Code for coding but do not use their git extension because I think SmartGit works better for me.

What I originally had in mind was not a VS code extension, but more like a connect via SSH.  If you have ever used MySQL or another database, you know some clients (SequelPro for example) have the capability to connect via SSH first then connect to the server. This process is largely for security reasons, however, the concept is an interesting one.

I would say the integration should just allow you to put in a remote ssh connection and a path so something like my-user@my-server-remote://var/www/source/ and then either a password or an ssh key. From there, the software would act like it does now, but instead of executing commands on the local computer, it would execute commands on the remote server and report the output in the output window.

The use case for this would be pulling code to a remote server without having to ssh manually into the server and type git pull (or whatever commands).

I understand that SmartGit has the capability to use an internal git or a external git binary, and obviously the server would be required to have the git extension installed, but these are problems that have basically already been solved in your software product in regards to local.

I posted this topic originally because I could not find any other git client that had this capability and it would be a super nice one to have. The combining of the best UX/UI experience of SmartGit with radical new features is something I"m on board for. Obviously if the lift is huge or the desire from the devs is not present that's understandable.

(FYI, here's an email I sent Syntevo a while back, with various performance stats for command-line git.)

I did some testing of git command-line performance, locally and networked. I found that working on shared file systems slows things down by a factor of 100 or more. A simple "git status" could take 80+ seconds (it once took almost five minutes). If that's true with the native git, then I can't really expect SmartGit to be faster.

Times to execute "git status" on the same repo (run repeatedly):

- SMB networked file system over WiFi (100BASE-T speeds): 55 seconds
(but file permissions were messed up)

- SMB networked file system over wired 1000BASE-T: 5 seconds (ditto)

- SSHFS networked file system over WiFi (100BASE-T speeds): 87 seconds
(first time took 297 seconds)

- SSHFS networked file system over wired 1000BASE-T: 17 seconds

- On local system (Recent 6-core Macbook Pro with flash storage): 0.210s

- On local system (Ubuntu w 8-core AMD processor and flash storage):
0.070s

So:

- Switching from WiFi to wired sped SMB up by a factor of 10, and SSHFS
by a factor of 6

- Switching from SSHFS to SMB sped up by factor of 0.6 to 5

- Running locally can be 1000 times faster.

I'm now using faster wired Ethernet (1000BASE-T), and things are now
tolerable. You might want to share this with the next person who
complains about slow networked functionality.

I think you are talking about running a git command from your local git binary on a mounted filesystem or somehow to a remote system, I was referencing running a server's local git on a remote system on it's own local file system. and reporting back ONLY the output.  GIT would have to be installed on the remote system and it the only network traffic would be the commands sent and the output returned.

I completely understand why what you are referencing would be an issue, but this is not the ask.

Interesting research you've done none the less. 

The problem is that SmartGit not just executes a few Git commands (like other Git clients do) and parses the output, but instead directly accesses the file system to read the files and especially the .git directory content, watching for file changes. Tunnelling this through SSH would mean to split a major part of SmartGit into 2 parts - not impossible, but a lot of effort. I reckon, not much users actually would want to have this feature if it would cost x00 USD extra.

I wouldn’t mind having a refresh button instead of auto refresh/watch for such a remote repository. 

Currently, if you use SmartGit on a network mounted filesystem it wont correctly report changes anyway, you have to reopen the repository to see them.

This isn’t a huge deal, however, and the only thing missing to get stuff done in a timely manner is the remote execution of git commands

Understood.  All the same, that's what would make SmartGit actually useful in practice, and I'd pay real money for it.  (Well, my employer's money :-)

My message posted 2 days ago is still waiting for moderation. Are you able to validate it ?

It would be very cool if I can use SmaritGit to work on my remote Code.

I'd like to +1 this feature. I have been a SmartGit user for I think 7 or 8 years now, and have watched how people have started transitioning their development to the cloud. VSCode is the obvious mention here (it exploded in popularity) but now even JetBrains have released a fully client-server model:

https://blog.jetbrains.com/blog/2021/11/29/introducing-remote-development-for-jetbrains-ides/

I think SmartGit's UI is superior to all competitors and IDEs but it's hard to deny that it must be really hard to attract new users when they start their careers by jumping on the remote train (not too uncommon now afaik), and then pick a git UI that works with it (or stick with terminal-only).

If you wanna think long-term about retaining paying customers (non-hobbyists at least), you might want to start considering that rewrite. Would be a shame if this project died in case the vast majority of devs just work on a VPS 5 years from now :(

Support for WSL using a remote execution layer would be  massively useful. I find myself using SmartGit less and less the current hacks are just too slow and buggy.

I need this feature too.

• On the same computer I had to install smartgit both on Windows and on Ubuntu under WSL, and to keep both instances to keep track of all my repos. The WSL version is buggy especially with regard to High DPI scaling.
• We manage many branches on a shared hardware for which the only access is ssh. As pointed out, shared fs are too slow for smartgit operation

With teleworking and cloud transitions, this feature becomes necessary and I think Smartgit needs to implement it to not lose paying clients.

I just found this thread while trying to find out if SmartGit supports working through SSH. I always had my repository directly on the development server, then needed to change my way of working when starting to use SmartGit. Now I have my repository locally and push all changes to the web server to test it.

This works but it's more cumbersome, all the more with working 3 days per week in home office and 2 days on site. Support of controlling a repository through SSH would be a huge advantage.

Of course as a developer I understand the reluctance of starting a complete rewrite, but on the other hand, in a competitive market it's all about going the extra mile …

I really need this feature

I've been subscribed to SmartGit for MANY years, but am starting to transition away to (inferior) VSCode Git support specifically because of this feature.  As time goes on and VSCode gets a better UI, it's very likely I'll end up canceling my subscription.

This feature is very important for anybody who wants to develop on: a headless/remote networked build server, the cloud, inside a Docker container (especially on Windows), etc...  This is only going to become more common over time.  In my case, I'm a systems engineer who cross-compiles ARM Linux distributions on a dedicated build machine which requires a very specific OS setup (e.g. specific Linux version) that I can't really install a full userland on.

What's needed is some way to efficiently work on Git repositories directly inside a remote machine over SSH.  How that works mechanically, maybe there's a way that doesn't require a complete rewrite?

I understand this this unlikely to ever happen, but just want to mention here that this is the direction the industry is heading, I think. Even the absolute top-end Laptops/PCs are simply nowhere powerful enough compared to what you can get using this method.

I myself am forced to stop using SmartGit after many years as well.

Agreed that this would be a very important feature. Currently I develop in an environment where there are multiple copies of the code+git repos on different virtual servers + local. On my local machine I use SmartGit but on the remote ones I'm forced to use command line git. Would be really nice to have the remote (via ssh) git repos similarly available side by side in my local SmartGit UI alongside the local repos. Otherwise I'm forced to look away from SmartGit for other tools. 

Currently, we don't have plans to implement this feature: until now, this workflow seems rather rare among (our Smart)Git users. On the other hand, this would require huge changes to SmartGit's code and overall architecture: SmartGit is doing lots of low-level access using internal Git libraries. This gives us better performance and more flexibility in implementing certain features. Introducing a client-server architecture in the core Git layer will most likely result in performance drawbacks for purely local users, or it would require to maintain two different implementations of certain algorithms which would make the change even more huge.

Other (popular) Git clients which do all the Git-related work exclusively by the git-executable can be adopted to this workflow much easier: run "ssh ... git <command>" instead of just "git <command>". But these clients usually suffer from worse overall performance or significant inflexibility, because where SmartGit will read a few bytes from a memory-mapped file, they have to invoke a new Git process to run a heavy-weight Git command.

I'm also not sure whether SmartGit is the right place to implement this client-server architecture: when generalizing this request, it would mean that every Git client would have to be changed to a similar client-server architecture. The remote machines would have to support the various server-side components to which the clients can then connect (as mentioned above, a "git" executable is not sufficient for SmartGit). To me this sounds more like the request for some new standard for a "Git server protocol", similar to the Language Server protocol, which would provide a low-level remote access onto the Git database. Hence, it could make sense to bring this entire topic to the attention of the Git community.

Concluding, it will be interesting to see into which direction the Software industry is developing. If this will become the prevailing workflow, we will have to swallow this bitter pill and implement it, too. But SmartGit will not be a first mover with respect to this topic (for the reasons outlined above).

@Marc: Thanks for this detailed explanation about the downsides and problems including SSH support.

However after reading this, I started wondering if there was not maybe a different way to achieve the same. What if SmartGit included a possibility to mount a server path with SSHFS and could then work with those files as if they were on the local disk?
Of course users can mount SSHFS manually, but when dabbling with that in the past on my Mac I found the available solutions quite lacking … I'm not sure if anything changed in the past 5 years. So wouldn't it be interesting for SmartGit to invest time on that end to get a solution built into the client directly?

No it would be too slow, all git process must run on the server-side

I do exactly this (manually), and it's still slow, even when using command line git.

I used to use sshfs but it wasn't stable enough. 

I would also love to have the functionality to work locally on a remote working copy. Having said that I also work with SmartGit (Linux version) running on a headless server (even on an HPC compute node) with the SmartGit windows simply on my laptop (Mac using the Quartz  X11  server, but I'm sure one could get it to work with a Windows X11 server). It is of course slightly laggy but works well enough for the more complicated things (for simple things I use the command line). 

I would use it at home. where I work on my YOMM2 project on a powerful headless Minisforum living in a cabinet, which I ssh to. And indeed I use a VS code remote ssh connection.

I would also use it at the office, where I have a similar setup.

I have seen vscode supplant IntelliJ for tens of thousands of developers and the main reason is vscode's remote support. I highly recommend smartgit actively look at how to support a similar remote model. I know its a big jump, but it seems necessary to remain competitive. Especially with semi-free options like vscode + free GitLens.