Git is distributed, meaning every copy is isolated and does not depends on other's copy. Adding remotes to an instance is mostly giving a name to an URL(URI?) for the fetch, pull, push operation, which exchange commits. As Commits are immutable and forms a chain, it's easy to know when two nodes diverge and conflict resolution can take place.
From the git-fetch(1) manual page:
> Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
You only need access to the other node repo information. There's no server. You can also use a simple path and store the other repo on drive.
Doable. It would basically be ssh but without encryption. You'd have to bang out login by hand, but "username\npassword\n" will probably work, might need a sleep inbetween, and of course you'll have to detect successful login too. Oh, and every 0xff byte will have to be escaped with another 0xff
At that point, may as well support raw serial too.
Supporting rlogin on the other hand is probably as simple as GIT_SSH=rlogin
The server is git itself, it contains two commands called git-receive-pack and git-upload-pack that it starts through ssh and communicate through stdin/out
You can think of the ssh://server/folder as a normal /folder. ssh provides auth and encryption to a remote hosted folder but you can forget about it for the purpose of understanding the nature of git model.
SSH is just a transport to get access to the repo information. The particular implementation does not matter (I think). Its configuration is orthogonal to git.
From the git-fetch(1) manual page:
> Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
You only need access to the other node repo information. There's no server. You can also use a simple path and store the other repo on drive.