What happens is that running
ssh git@host perms reponame
appears to hang, since it is waiting for STDIN. I added a message to
help, since we don't want users losing files accidentally!
(The other alternative is to add a specific option for batch mode, but
this is backward incompatible for people who have scripts that may be
doing this).
thanks to Caleb Cushing for catching this
----
The "make sure Ctrl-C gets caught" thing needs some explanation.
Without it, a user could inadvertently lose his gl-perms file if he ran
the command in batch mode. You'd think that the Ctrl-C would hit the
for (<>) {
line and bail, but it manages to reach the
_print( $pf, @a );
line somehow. Even trapping SIG INT does not help.
I suspect it is to do with how signals are propagated by ssh across a
"no-pty" session, but am not sure.
Sometime after v3.2, I fixed what looked like an information disclosure
issue, where a user could determine if an arbitrary repo existed or not,
even if he had no rights to see the repo. This was:
96cc2ea "new features relating to creating wild repos:"
Unfortunately, this appears to have broken gl-perms propagation to
slaves, because now running "perm -c" on an existing repo dies!
If you run
git diff 96cc2ea^ <this commit> -- src/commands/perms
you'll see how simple the fix *should* have been :-(
- new 'create' command for explicit creation
- new 'AutoCreate' trigger to prevent auto-creation on read operations
or both read and write operations
- a few related fixups to the perms command
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
