[Cryptech Core] Two proposed changes to gitolite configuration

Rob Austein sra at hactrn.net
Thu Nov 6 22:36:11 UTC 2014


At Wed, 05 Nov 2014 18:22:04 -0500, Rob Austein wrote:
> 
> 1) We've talked about having a user/ tree.  While we can do that
>    already with the current configuration, the Principle of Least
>    Astonishment suggests that, by default, nobody but user foo should
>    be allowed to create or push to user/foo/bar.  In theory this is a
>    four line addition to the config file (it's even documented).

But of course nothing with gitolite is every really simple.

The substantive issue here is whether we really want to enforce any
particular kind of repository naming structure.  If we can agree on a
set of rules, I can encode it in the gitolite config.  Right now, it's
first come first served except for the reserved name for gitolite's
own control repository.

The gitolite-specific silly issue is that gitolite's idea of a user
name in this configuration is a complete email addreses.  So my tree
would not be user/sra/, it would be user/sra at hactrn.net/, which
probably violates the Principle of Least Astonishment for half a dozen
other tools.  Keeping in mind that there are several manual steps to
creating a new authorized user, manually adding a user/foo/ rule for
that user at the same time is not a big deal, so if we decide that we
want a more locked down configuration, this username silliness need
not stand in the way.

So the question is: do folks want to commit to a particular hierarchy
and lock down to it, or leave it alone for now?

> 2) I've come to the conclusion that, at least for our purposes,
>    gitolite's default behavior of creating an empty repository when
>    one clones a repository that doesn't exist is probably a mistake.
...
>    2a) Disable create-on-clone but continue to allow create-on-push.
> 
>    2b) Disable automatic creation entirely, so creating a new
>        repository would require an explicit command:
> 
>        $ ssh git at git.cryptech.is create foo/bar

I configured for (2a), but in practice it works like (2b), because git
kind of wants to pull before pushing when one tells it about a new
repository.  Maybe the git wizards on this list will have some use for
the create-on-push behavior, but for most purposes I think it's
simpler just to use the explicit create command as shown above.

Note that, gitolite not being known for every doing anything the easy
way, one must specify the repository **without** the trailing .git in
the create command to avoid accidentally creating foo/bar.git.git.



More information about the Core mailing list