4 ms·

What you are talking about is remotely accessing and working on a codebase. That has nothing to do with repository management. As mprime1 replied, it's more on

What you are talking about is remotely accessing and working on a codebase. That has nothing to do with repository management. As mprime1 replied, it's more on the lines of firing up the terminal to create the git repository. Then go back to your local system and git clone/pull the thing. Then you fire up your local VSCode and work on it and then finally push the changes. This way the whole team can work seamlessly and implement CI/CD while addressing conflicts in real time. What you are talking about is a beautiful way to work on a remote machine (especially the headless ones) but only when you are the single dev. For a team, you gotta go the other way.

teekert 4y ago
Thanx for the explanation, so if you create the repo on the server, can you just got clone server.ip then? How do you clone it? Does that git init —bare command create a server?
- saurik 4y ago
  git clone teekert@ssh.example.com:path/like/scp If you also want public access over http you can activate one of the default hooks (so a single "rename a file" command on the server) and then export it using literally any web server software (as it is a folder of dumb files).
  - teekert 4y ago
    Ah! Somehow I was assuming some magic in the cloning, some server-client relation. There is not I guess, and that is actually logical. Also refreshing in a way.
    - saurik 4y ago
      FWIW, I do believe that you have to have git installed on the other side, and what it is doing at an implementation level is using ssh to run a transient copy of the git daemon backed by that path on the remote machine, which communicates over stdin/stdout--and so over ssh--and which implicitly (due to the EOF) dies when the ssh connection dies. Like, I don't think it is accessing the remote side using mere scp/sftp file-system operations or anything (which would be horribly slow for a number of basic operations and would make cleanly running triggers and the such more annoying).
      - teekert 4y ago
        Thanx for this reply!
sumanthvepa 4y ago
Why would this not work for a small team?

teekert 4y ago

Thanx for the explanation, so if you create the repo on the server, can you just got clone server.ip then? How do you clone it? Does that git init —bare command create a server?

saurik 4y ago
git clone teekert@ssh.example.com:path/like/scp If you also want public access over http you can activate one of the default hooks (so a single "rename a file" command on the server) and then export it using literally any web server software (as it is a folder of dumb files).
- teekert 4y ago
  Ah! Somehow I was assuming some magic in the cloning, some server-client relation. There is not I guess, and that is actually logical. Also refreshing in a way.
  - saurik 4y ago
    FWIW, I do believe that you have to have git installed on the other side, and what it is doing at an implementation level is using ssh to run a transient copy of the git daemon backed by that path on the remote machine, which communicates over stdin/stdout--and so over ssh--and which implicitly (due to the EOF) dies when the ssh connection dies. Like, I don't think it is accessing the remote side using mere scp/sftp file-system operations or anything (which would be horribly slow for a number of basic operations and would make cleanly running triggers and the such more annoying).
    - teekert 4y ago
      Thanx for this reply!

sumanthvepa 4y ago

Why would this not work for a small team?