[mejutoco]

In case anybody is interested, having a bare git repo on a server is as easy as:

    # locally
    ssh [e-mail]
    
    # server
    mkdir repo.git  
    cd repo.git  
    git --bare init
    
    # locally
    git remote add origin ssh://[e-mail]/home/git/repo.git  
    git push origin master

P.S. I know it does not have the same features as github

[stephenr]

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.

[mejutoco]

I prefer to be explicit about which user is connecting to ssh.

[kbolino]

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]

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,...)

[kbolino]

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.

[SpaceNoodled]

It has all the same working features as github