src/VREF/EMAIL-CHECK

   1 #!/usr/bin/perl
   2
   3 # gitolite VREF to check if all *new* commits have author == pusher
   4
   5 #                       THIS IS NOT READY TO USE AS IS
   6 #                       ------------------------------
   7 #           you MUST change the 'email_ok()' sub to suit *YOUR* site's
   8 #           gitolite username -> author email mapping!
   9
  10 # See bottom of the program for important philosophical notes.
  11
  12 use strict;
  13 use warnings;
  14
  15 # mapping between gitolite userid and correct email address is encapsulated in
  16 # this subroutine; change as you like
  17 sub email_ok {
  18     my ($author_email) = shift;
  19     my $expected_email = "$ENV{GL_USER}\@atc.tcs.com";
  20     return $author_email eq $expected_email;
  21 }
  22
  23 my ( $ref, $old, $new ) = @ARGV;
  24 for my $rev (`git log --format="%ae\t%h\t%s" $new --not --all`) {
  25     chomp($rev);
  26     my ( $author_email, $hash, $subject ) = split /\t/, $rev;
  27
  28     # again, we use the trick that a vref can just choose to die instead of
  29     # passing back a vref, having it checked, etc., if it's more convenient
  30     die "$ENV{GL_USER}, you can't push $hash authored by $author_email\n" . "\t(subject of commit was $subject)\n"
  31       unless email_ok($author_email);
  32 }
  33
  34 exit 0;
  35
  36 __END__
  37
  38 The following discussion is for people who want to enforce this check on ALL
  39 their developers (i.e., not just the newbies).
  40
  41 Doing this breaks the "D" in "DVCS", forcing all your developers to work to a
  42 centralised model as far as pushes are concerned.  It prevents amending
  43 someone else's commit and pushing (this includes rebasing, cherry-picking, and
  44 so on, which are all impossible now).  It also makes *any* off-line
  45 collabaration between two developers useless, because neither of them can push
  46 the result to the server.
  47
  48 PHBs should note that validating the committer ID is NOT the same as reviewing
  49 the code and running QA/tests on it.  If you're not reviewing/QA-ing the code,
  50 it's probably worthless anyway.  Conversely, if you *are* going to review the
  51 code and run QA/tests anyway, then you don't really need to validate the
  52 author email!
  53
  54 In a DVCS, if you *pushed* a series of commits, you have -- in some sense --
  55 signed off on them.  The most formal way to "sign" a series is to tack on and
  56 push a gpg-signed tag, although most people don't go that far.  Gitolite's log
  57 files are designed to preserve that accountability to *some* extent, though;
  58 see contrib/adc/who-pushed for an admin defined command that quickly and
  59 easily tells you who *pushed* a particular commit.
  60
  61 Anyway, the point is that the only purpose of this script is to
  62
  63   * pander to someone who still has not grokked *D*VCS
  64           OR
  65   * tick off an item in some stupid PHB's checklist
  66