This is the mail archive of the
mailing list for the glibc project.
glibc git commit hooks update.
- From: Carlos O'Donell <codonell at redhat dot com>
- To: libc-alpha <libc-alpha at sourceware dot org>
- Cc: Mark Wielaard <mjw at redhat dot com>, Nick Clifton <nickc at redhat dot com>, Jeff Law <law at redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, Pedro Alves <palves at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Mon, 15 Apr 2019 15:29:16 -0400
- Subject: glibc git commit hooks update.
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
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
* 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
* 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.
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*
* 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
* 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: -- 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: -- Commit emails will therefore not be sent.
* 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: *** commit 68d5c2453a221ed6384c3e78a75e8b443b0c56ad
remote: *** Subject: Test commit
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.
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.