[Cryptech Core] git repository usage patterns and access control

[Linus Nordberg]

Rob Austein <sra at hactrn.net> wrote
Mon, 06 Oct 2014 16:23:59 -0400:

| 2) Same as (1), but adopt a github-like work pattern where developers
|    who want to hack each other's code fork the repository.  gitolite

This is what I would suggest. I'd also like to explain how I like
software projects with multiple developers and git. If this model suits
the work flow for Cryptech too, I don't know.

For a given "project" (i.e. repository), each developer has their own
repository. Perhaps under /user/$NAME/. Only $NAME can push to repos
under /user/$NAME/.

For a given "project", there is also "the main" repository, or perhaps
better "the official" repository. One or more (hopefully at least two)
maintainers have push access to it. They merge changes from topic
branches in other repositories into this official repository. This is
where we point people. This is what we make releases from.

This is how Tor Project uses git and I find it very useful and
workable. We're mimicing this in the Catlfish project [1].


|    even has some direct support for this:
| 
|    $ ssh git at git.cryptech.is fork <repo1> <repo2>
| 
|    gitolite does allow authorized users to delete their own
|    repositories, but it's tedious enough that I suspect adopting this
|    work pattern would result in a clutter of single-use repositories
|    that nobody can be bothered to clean up.  Maybe that's OK (ick), or
|    maybe there's some stylized way of doing this that would allow us
|    to clean up old forks automatically (needs thought).

Forking can also be done by cloning and pushing, like so

  $ git clone https://git.cryptech.is/foo.git
  $ git remote add linus ssh://git@git.cryptech.is/user/linus/foo.git
  $ git push linus

Unused repos are OK. It's just data.


[1] https://www.ct.nordu.net/