glibc git commit hooks update.

[Carlos O'Donell <codonell at redhat dot 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.