perms command batch mode, without creating repositories?

[Craig de Stigter]

Hi folks

We've started using the batch mode of the perms command to set perms from an external system.

One problem is that the batch mode requires `-c`, which creates the repo if it doesn't exist. However, not all of the objects in our system have repos attached, and we don't want to create useless empty repos.

So at present we first have to check if the repo exists, and then we can run the perms command with -c.

IMO It would be better if there was a separate flag for batch mode (I see in 2016 someone proposed a `-b` flag for batch mode) which didn't create empty repositories. Would that be considered? If so I will prepare a patch.

Thanks

Craig

[Sitaram Chamarty]

On Wed, Jul 01, 2020 at 01:54:33PM -0700, Craig de Stigter wrote:
>
> Hi folks
>
> We've started using the batch mode of the perms command to set perms from
> an external system.
>
> One problem is that the batch mode requires `-c`, which creates the repo if
> it doesn't exist. However, not all of the objects in our system have repos
> attached, and we don't want to create useless empty repos.
>
> So at present we first have to check if the repo exists, and then we can
> run the perms command with -c.

Just to recap, "perms -c" works like this:

cat copy-of-backed-up-gl-perms | ssh git@host perms -c <repo>

and it creates the repo if needed.

I'm trying to understand why you would need to run a "perms -c"
against a repo that you do NOT want to create. Why should
anyone be passing reponames to gitolite that should not exist?

That is a somewhat strange use case, and I am not convinced that
gitolite needs to support it in the upstream version.

Note that commands (and triggers) are not considered "core", and
gitolite explicitly allows you to override shipped commands with
your own variants; see [1] and perhaps also [2].

So you can always replicate the `perms` script on your own
installation, with lines 57 to 65 replaced with a simple `exit;`
(not tested; please test!)

Hope this helps. If I have totally misunderstood the problem
please add some details to help me understand!

[1]: https://gitolite.com/gitolite/non-core.html
[2]: https://gitolite.com/gitolite/cookbook.html#adding-your-own-commands

regards
sitaram

[Craig de Stigter]

Thanks for the reply.

Why should anyone be passing reponames to gitolite that should not exist?

I'll try to explain what we're doing.

We have a large external system containing a bunch of things stored outside of git / gitolite, and we are slowly mirroring them into git repos stored in gitolite. As we build the mirroring process and fix issues with it, more and more of our data will be imported into gitolite repos. We will eventually end up with several tens of thousands of repositories.

We also have our own in-house permissions system. Likewise, we want the permissions for the repos in gitolite to always match the permissions we have in our in-house system, which may change irrespective of the changes in the data we're mirroring. This is what we're using the batch mode of the perms command for - to sync permissions from our in-house permissions system with the gitolite repo permissions.

Since many of the objects we're mirroring don't yet exist in gitolite, we need a way that the permissions mirroring can fail gracefully if the repo doesn't exist. At present we're using `ssh <host> perms <repo> -l`, and checking the exit code to determine if the repo exists. However we'd much prefer a single-command solution because it would be simpler and less prone to race conditions.

Note that commands (and triggers) are not considered "core", and gitolite explicitly allows you to override shipped commands with your own variants; see [1] and perhaps also [2].

Thanks, I hadn't realised it was that easy to override shipped commands; we'll look into that.

Cheers

Craig

--

Regards,

Craig

Developer

Koordinates

+64 21 256 9488 / koordinates.com / @koordinates