4 ms·

In case anybody is interested, having a bare git repo on a server is as easy as: # locally ssh git@example.com # server mkdir repo.git

In case anybody is interested, having a bare git repo on a server is as easy as: # locally ssh git@example.com # server mkdir repo.git cd repo.git git --bare init # locally git remote add origin ssh://git@example.com/home/git/repo.git git push origin master P.S. I know it does not have the same features as github

SpaceNoodled 7mo ago
It has all the same working features as github
stephenr 7mo ago
If it's your ssh server and it's single user you don't need to use the "git@" part at all. Just store the repo and access it with your account. The whole git@ thing is because most "forge" software is built around a single dedicated user doing everything, rather than taking advantage of the OS users, permissions and acl system. For a single user it's pointless. For anyone who knows how to setup filesystem permissions it's not necessary.
- kbolino 7mo ago
  There isn't much advantage that can be taken from O/S users and perms anyway, at least as far as git is concerned. When using a shared-filesystem repository over SSH (or NFS etc.), the actually usable access levels are: full, including the abilities to rewrite history, forge commits from other users, and corrupt/erase the repo; read-only; and none.
  - skydhash 7mo ago
    Git was build to be decentralized with everyone having its own copy. If it's an organization someone trusted will hold the key to the canonical version. If you need to discuss and review patches, you use a communication medium (email, forums, IRC, shared folder,...)
    - deleted 7mo ago
      [deleted]
    - kbolino 7mo ago
      Git was built to be decentralized but it ended up basically displacing all other version control systems, including centralized ones. There are still some holdouts on SVN and even CVS, and there are niche professional fields where other systems are preferred due to tighter integration with the rest of their tools and/or better binary file support, but, for most people, Git is now synonymous with version control.
- mejutoco 7mo ago
  I prefer to be explicit about which user is connecting to ssh.

SpaceNoodled 7mo ago

It has all the same working features as github

stephenr 7mo ago

If it's your ssh server and it's single user you don't need to use the "git@" part at all. Just store the repo and access it with your account. The whole git@ thing is because most "forge" software is built around a single dedicated user doing everything, rather than taking advantage of the OS users, permissions and acl system. For a single user it's pointless. For anyone who knows how to setup filesystem permissions it's not necessary.

kbolino 7mo ago
There isn't much advantage that can be taken from O/S users and perms anyway, at least as far as git is concerned. When using a shared-filesystem repository over SSH (or NFS etc.), the actually usable access levels are: full, including the abilities to rewrite history, forge commits from other users, and corrupt/erase the repo; read-only; and none.
- skydhash 7mo ago
  Git was build to be decentralized with everyone having its own copy. If it's an organization someone trusted will hold the key to the canonical version. If you need to discuss and review patches, you use a communication medium (email, forums, IRC, shared folder,...)
  - deleted 7mo ago
    [deleted]
  - kbolino 7mo ago
    Git was built to be decentralized but it ended up basically displacing all other version control systems, including centralized ones. There are still some holdouts on SVN and even CVS, and there are niche professional fields where other systems are preferred due to tighter integration with the rest of their tools and/or better binary file support, but, for most people, Git is now synonymous with version control.
mejutoco 7mo ago
I prefer to be explicit about which user is connecting to ssh.