> Everyone’s username is git. How does the server distinguish who is who?

I used to run a small gitolite/redmine installation for a few years. I found its solution to this problem very "unix"-y[0] - Just manage the `authorized_users` file to set the `command=` for each user individually. The file looks like:

    command="[path]/gitolite-shell sitaram",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA18S2t...

The gitolite-shell script gets the `$SSH_ORIGINAL_COMMAND` from sshd, and uses that to pick the repo name/path. Then it uses the $ARGV to get the actual user. It can then decide on access rules.

For branch/tag restrictions, it uses git hooks that are setup at repo creation.

[0]: https://gitolite.com/gitolite/glssh.html

It's also interesting to see how this compares with Gerrit, which uses JGit as the git protocol frontend and stores everything, including all metadata about the code review process and permissions systems, within git repos using a format called NoteDb:

https://gerrit-review.googlesource.com/Documentation/dev-des...

While it does use separate file-based databases, these are generally only to speed up operations and are not a source of truth.

good stuff, thank you!

I was hoping it was going to get into this wizardry, which I use a great deal: https://docs.gitlab.com/ee/user/project/push_options.html#pu...

  git push -o ci.variable=CI_TRACE_DEBUG=1 -o merge_request.create origin HEAD

although I'll be straight, there is waaaaaaaay too much ruby magick going on for my tastes so I tend not to try and be a hero with the variables if it's more complicated than just "-o ci.skip" or that trace debug one. Once upon a time I did some spelunking around in their abysmal rails codebase trying to find out, what, exactly syntax I can use and that's how I came to the "don't be a hero" stance because it was super opaque (yeah, yeah, I know: MRs welcome)