glibc git commit hooks update.

[Carlos O'Donell <codonell@redhat.com>]

Dear Community,

Florian Weimer and myself have upgraded the glibc commit hooks
to use the common hooks from AdaCore scripts with Red Hat
customizations. These hooks are also being used by binutils
and valgrind and is part of the common infrastructure on
sourceware (/sourceware/projects/src-home/git-hooks).

Our goals were to improve developer workflow, particularly
around user branches and bugzilla noise. We wanted users to
be able to experiment quickly, throw away branches, and
present clean branches to maintainers for review. This meant
rebases and no bugzilla noise.

Concrete goals were:

* User branches should allow rebases.
* User branch updates should not send messages to bugzilla.
* Ensure merges are disabled to master and release branches.
* Less verbose bugzilla updates.

We completed the transition including commissioning tests.

You will immediately see the following benefits:

* User branches (non-master, non-release branches) can now use
   non-fast-forward merges. You do not need to delete and recreate
   your branch.

* User branch commits do not generate emails, or bugzilla updates
   for any reason. Previously we would update bugzilla when any
   branches had commits that mentioned the bug, and this is no
   longer true.

* glibc-cvs and bugzilla will now use a more succinct form of
   update description that includes who did the push, and a very
   succinct description of the single commit.

   e.g. https://sourceware.org/bugzilla/show_bug.cgi?id=16573#c5

   e.g. https://www.sourceware.org/ml/glibc-cvs/2019-q2/msg00038.html

   Note: Scripts that parse this output may need updating.

* Style check applies only to sources files and make files and
   avoids data files by using known extensions. You can now commit
   whitespace changes to data files.

   e.g. *.[ch], *.cpp, *.cc, *.[Ss], *.py, *.awk, manual/*,
        scripts/*, *.mk, and */Make*

Limitations:

* Sending an email and updating bugzilla are the same process,
   and so you either get both or you get none. You cannot have
   commit emails without bugzilla updates. Therefore we have opted
   to have only commit emails and bugzilla updates for release and
   master. This can be fixed but it needs extending in the existing
   scripts to make the two operations distinct. For example if anyone
   wants user branches to generate email commit messages then we'll
   need to work on this.

* Style check is applied to the whole file not the diff of the changes.
   As of today all the source files are clean. This should not make a
   difference to the project, but it is a difference in the way the
   hooks operate.

Commissioning:

* Tested that user branches can be rebased.
* Tested that user branch commits do not generate emails or bugzilla updates.

It's a little noisy locally:
remote: ----------------------------------------------------------------------
remote: --  The hooks.no-emails config option contains `refs/heads/(?!master|release.*)',
remote: --  which matches the name of the reference being updated
remote: --  (refs/heads/fw/bug21242).
remote: --
remote: --  Commit emails will therefore not be sent.
remote: ----------------------------------------------------------------------

* Tested that merge commits are not allowed on master and release branches.

remote: *** Merge commits are not allowed on refs/heads/master.
remote: *** The commit that caused this error is:
remote: ***
remote: ***     commit 68d5c2453a221ed6384c3e78a75e8b443b0c56ad
remote: ***     Subject: Test commit
remote: ***
remote: *** Hint: Consider using "git cherry-pick" instead of "git merge",
remote: ***       or "git pull --rebase" instead of "git pull".

* Verified format of output to bugzilla and glibc-cvs is succinct.

   Examples:

   Before: https://sourceware.org/bugzilla/show_bug.cgi?id=16573#c3
   After: https://sourceware.org/bugzilla/show_bug.cgi?id=16573#c5

   Before: https://www.sourceware.org/ml/glibc-cvs/2019-q2/msg00031.html
   After: https://www.sourceware.org/ml/glibc-cvs/2019-q2/msg00037.html

Thank you very much for your patience.

It is our sincerest hope that these changes will make developing
on glibc much better.

If you have any problems with these changes please reach out
to me or Florian to discuss the update.

-- 
Cheers,
Carlos.