I like using Git software to push commits, but the ones I use (Gitbox, Github, SourceTree) all ask for a local repo when adding a new repo to them.
Thing is, my repo is
One solution, which doesn't rely on the front-end to support manipulating a remote repo directly, would be to mount the remote as a networked filesystem. If you only have SSH access to the remote machine, you could try using SSHFS via FUSE (on Linux) or OSXFUSE on Mac OS X. Or depending on your preferences and setup, you could use SMB, NFS, DAV, or another network filesystem.
Another way to do it, that I bring up in the comments, is to export the network filesystem from your development machine to your server. I do this so that I can mount my current working copy on multiple machines at once, and also so that I still have my local working copy even when I'm not connected to the server.
You write:
I am surprised git software can't deal with remote repos as the working version.
Most Git GUIs do some of their work by calling out to the git
command. In order for them to support remote operation, core Git would have to as well. It is written in a mix of C and shell script; all of that would have to be rewritten to cope with remote files.
A text editor has a much easier job; it reads one file when you open it, and writes when you save, while Git reads and writes many files in the course of a single operation like commit
.
A networked filesystem would mean that all tools (Git and otherwise) will work on your remote files. Instead of building a layer into each and every application to support networked file access, doing it in the kernel (or via FUSE) and then just treating it like a local filesystem gives you that support in every application for free.