2

My company has a distributed system in which a remote CentOS machine allocates worker's home directories with all our git repos working, built and executed on it.

In my local machine (Ubuntu), I've the remote home directory mounted over NFS to be able to edit the files with my favourite IDE.

For managing the version control I want to use GitKraken on my local machine (there is no SSH tunneling) but is extremely slow. If I use git from command lines connecting the remote machine over SSH performance normally. If I execute the same in my local it's slowered but still usable. I guess that GitKraken makes more operations in the background which makes accumulated delays.

Is there a way to improve the performance or a better way to work with this requirements? Being able to use GitKraken and vsc locally.

I have already try several things like: mounting with systemd, sshfs, cleaning repositories with git gc, refreshing git indexes in my local machine (because the I've read It could influence the creation in CentOS vs Debian), improve NFS options and cache...

PS: I had a crazy idea to improve Git's performance. I created a Git alias on my local machine that first connects to the remote machine via SSH:

alias git='ssh -A <user>@<host> "cd ${PWD} && git"'

This significantly improved performance compared to using Git on NFS-mounted repositories.

While I know that there are probably ways to further improve performance using Git config proxies, and while this approach has its inconveniences, it was acceptable in my case. However, my main interest was in using GitKraken.

Since GitKraken uses its own Git implementation (libgit2), it does not rely on the Git installed on the bare machine. In that aspect, my hands are tied.

Ray
  • 113
  • 1
  • 15
  • Working with a git repository over NFS has traditionally caused many minor (and a few major) problems. While many of those are fixed with modern NFS setups, some may still linger. If the git repository is remote, maybe one approach would be to work fully remote (for example using VScode remote connections where the majority of the IDE runs on your remote machine and only the frontend runs locally). – Joachim Sauer Apr 13 '23 at 08:47

1 Answers1

3

Ideally, You would store only bare repositories on your remote CentOS machine.
That way, you can:

  • clone them locally
  • work locally (add/commit/push through CLI or GitKraken)
  • push back

Most of your day-to-day operation would therefore be local ones.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It can't be do it like that, the repositories in the remote machine are running. This way reduce consuming local resources and allows us to work remotelly easily. When I change code locally I can see changes in the webs running in remote. – Ray Mar 31 '23 at 11:54
  • @Ray You can push them and add to those bare remote repository a [`post-receive` hook](https://stackoverflow.com/a/75862931/6309) which will publish the content and update those website. – VonC Mar 31 '23 at 11:58
  • It's a development environment running on a remote machine. Having to commit and push code modifications each time you want to see the results doesn't fit for me. – Ray Mar 31 '23 at 13:44
  • @Ray Can you try and test your website locally? That way, when you are ready, you can push all your commits to the remote server. – VonC Mar 31 '23 at 15:20
  • @Ray The basic idea is: to avoid any performance issue, re-create your development environment locally, with a local Git repository, then push to the remote production server. – VonC Mar 31 '23 at 15:20
  • No, that's the key of this way of work. Every lib and dependency is only installed in the remote machine, local machine is clean and can even have the OS we want. What you are proposing is just taking the remote machine like a deployment layer above – Ray Mar 31 '23 at 16:15
  • 1
    @Ray Exactly: considering your development would need to access the server with terrible performance, it is best to replicate said development locally, in a VM or a Docker container (that way, you leave your OS clean), instead of trying to optimize a network connection. – VonC Mar 31 '23 at 18:08