Commits on Mar 27, 2013
  1. (bugfix) (v3.5.1) fix permissions of projects.list file

    update-gitweb-access-list had a change recently (289b19d) that had a
    side-effect of making projects.list unreadable by other userids (like
    'apache' or whatever).
    This makes 3.5 unusable for anyone using gitweb.  (Hence the new tag,
    too, though 3.5 is only the previous commit and this is a very small
    committed Mar 25, 2013
Commits on Mar 24, 2013
  1. v3.5

    committed Mar 24, 2013
  2. overwrite projects.list atomically

    avoids any potential race conditions between triggers being run
    concurrently, and probably avoids gitweb picking up a half-done file too
    jefferai committed with Mar 23, 2013
Commits on Mar 21, 2013
Commits on Mar 17, 2013
  1. list-memberships and perms changes:

      - list-memberships now requires a '-r' or '-u'; i.e., you have to
        explicitly state whether you are passing a reponame or a username
        see the new '-h' message for details.
      - now has a new 'in_role()' test that is, at present, only
        used by 'owns()', which uses that instead of checking that he is the
        The role name used (I recommend "OWNER") must be set in the rc file
        like so
            OWNER_ROLENAME => 'OWNER',
        and if it is not set, defaults to 'CREATOR', which makes it behave
        as things currently do.
      - perms now uses this new 'owns()' function to authorise the user,
        instead of checking that she is the *creator*
    committed Mar 17, 2013
Commits on Mar 12, 2013
  1. add a contributing document

    text is pulled out of the wiki.  This will enable github to show a link when
    a contributor creates an issue or opens a Pull Request
    jokajak committed with Mar 12, 2013
Commits on Mar 6, 2013
Commits on Mar 5, 2013
  1. v3.4

    committed Mar 5, 2013
  2. refex-expr

    committed Mar 3, 2013
Commits on Mar 3, 2013
  1. rc file format change (please read below)

    First: if you have an old rc file it will still work.  In fact
    internally the new rc file data gets converted to the old one.  So you
    do not have to do anything normally.
    This changes the rc file in the following way, taking mirroring as an
    example.  Simple enough for most purposes but you really should read the
        INPUT                       =>
        PRE_GIT                     =>
        POST_GIT                    =>
        ENABLE  =>
            # COMMANDS
                ... several commands ...
            # Triggers
                ... several triggers ...
    committed Jan 10, 2013
Commits on Mar 2, 2013
  1. (minor) README docfix about empty config values

    (this should have been part of d8df4a9)
    sral committed with Mar 2, 2013
Commits on Feb 28, 2013
Commits on Feb 27, 2013
Commits on Feb 24, 2013
  1. Fix a warning about ambiguous shift usage

    [committer's note: newer perl's don't have this problem, but 5.8.8 at
    least appears to require the parens]
    jwadamson committed with Feb 24, 2013
Commits on Feb 18, 2013
  1. allow non-gitolite keys to have options/command, etc

    Apparently, ssh-keygen can take fingerprints of entire authkeys files
    also.  This is totally undocumented.
    Since 'man ssh-keygen' only says: "Show fingerprint of specified public
    key file." and makes no mention of authorized_keys files, I had assumed
    that it treated a file containing this
        command="/usr/bin/backup" ssh-rsa .....
    (i.e., a non-gitolite key that nevertheless contains a command) as just
    a special type of pubkey file.  This meant, to me, that the presence or
    absence of a newline should not matter, because *without* the 'command='
    it certainly doesn't.
    But what's actually happening is that it is treating this as an
    authorized_keys file, and in *that* mode, it requires a newline.
    I still don't see why it should require a newline as a *terminator*;
    having it as a *separator* should be sufficient, but it's pointless to
    argue about that when the feature itself is undocumented.
    Wizmaster (code at wizmaster at fr) had to dig into the openssh source
    code to figure this out and explain it to me.
    committed Feb 18, 2013
Commits on Feb 5, 2013
  1. fix typo in ssh-authkeys

    hemmecke committed with Jan 24, 2013
Commits on Jan 24, 2013
  1. (minor) perms would not print the correct message sometimes...

    i.e., if getperms had an error.  (The same error for setperms would
    print the correct message)
    committed Jan 24, 2013
Commits on Jan 23, 2013
  1. sshkeys-lint: accept ecdsa keys also

    thanks to Richard Salts
    committed Jan 23, 2013
Commits on Jan 11, 2013
  1. access(): the pattern for refs is too strict for filenames

    a filename also becomes a "ref" if you use VREF/NAME.
    For some reason[1], it seems some people use crazy filenames like foo(0)
    or bar%20baz, and these things blow up on that test.
    [1] viz., the lack of someone with good taste, like me, leading their
    project ;-)
    committed Jan 11, 2013
Commits on Jan 8, 2013
  1. should mention $HOME also

    ...thanks to Alan Ott
    committed Jan 8, 2013
Commits on Jan 7, 2013
  1. update-git-configs: 'SAFE_CONFIG'...

    allow macros to ease the pain of UNSAFE_PATT
    See or equivalent.
    committed Jan 7, 2013
Commits on Dec 31, 2012
  1. on removing a repo...

    Not following through on instructions to remove a repo, per [1], is not
    sufficient.  Even if you did just the first step, the repo should  no
    longer be accessible.  See [2] for discussion.
    As a bonus, we get rid of one pesky warning that always confused people.
    (In hindsight -- this confusion itself should have been a warning that
    something is wrong and needed fixing!)
    committed Dec 31, 2012
  2. list-dangling-repos: are we there yet?

    <sigh>First I forgot @groups that may contain repos and patterns, then I
    forgot patterns where the CREATOR token is used (this is the fix here).
    committed Dec 31, 2012
Commits on Dec 29, 2012
  1. v3.3

    committed Dec 29, 2012
  2. perms batch mode confuses; print something to help

    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.
    committed Dec 29, 2012
  3. bug fix: perms propagation to slaves...

    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 :-(
    committed Dec 29, 2012
  4. minor bugly...

    please remember we make up words here, like refex was a word we created
    to mean "a regex that matches a ref".
    A "bugly", then, is a bug that's merely ugly (and not a real problem!)
    committed Dec 29, 2012
Commits on Dec 19, 2012
  1. fix bug in list-dangling-repos

    Still, I would advise caution if you use this as a basis for deleting
    repos from the file system.  A bug in this program could cause you to
    lose important data!
    committed Dec 19, 2012
  2. CREATOR need only be a "word" in wild repo patterns

    this was a v2 compat breakage, caught by Dominik Schäfer
    (schaedpq at gmail)
    committed Dec 14, 2012
Commits on Dec 14, 2012
  1. add more detail to error message

    this error normally happens due to some permission issue on the log
    file, but we weren't printing the actual cause, so it was confusing
    committed Dec 14, 2012