Re: AdaCore git hooks for binutils-gdb git repo

[Joel Brobecker <brobecker at adacore dot com>]

> Valgrind source code repository is going to migrate from SVN to git
> SCM, hosted at sourceware.org. I am driving the migration effort [3]
> and would like to sync with binutils-gdb project with regards to using
> AdaCore git hooks on sourceware.org.

Sure!

> I have found and studied gdb's guide to AdaCore git hooks [1] and Mark
> W. discovered actual configuration used by binutils-gdb project:
> 
> [hooks]

Actually, I believe the config that Mark found might be coming
from the "config" file in the .git (bare) repository. But
the git-hooks no longer take their information from that
file. Instead, they take it from a file called project.config,
provided by a special "branch" refs/meta/config.

You'll find gdb's current configuration via:

    $ git fetch origin refs/meta/config
    $ git show FETCH_HEAD:project.config

> It looks like the guide [1] is [slightly] outdated now and the
> configuration reflects development
> of AdaCore hooks and maybe also development of binutils-gdb internal policies.

The documentation should be up to date. Normally, it's part of
my SOP to update them anytime I make a change.

> With your permission, we (Valgrind developers) would like to
> coordinate on sharing your setup for AdaCore git hooks by:
> 1) Utilizing the current git-hooks checkout [2] and adapting the
> configuration to our needs

Of course. I can help with the configuration as well.

> 2) Letting us know of any updates to binutils-gdb hooks config so we
> can double check ours

For now, I only know of two repositories that use the git-hooks
on sourceware.org, so I am happy adding one more destination
to publish any updates. I've started a list of email lists
I need to contact to announce those updates at:

What's the valgrind developer's mailinglist address, so I can add it
to the existing list?

> For the start, I don't understand why current binutils-gdb config does
> not define "from-domain" option even if [1] claims it is necessary. Do
> you have an idea?
> 
> Also previous hooks.reject-merge-commits option seems to have evolved
> into hooks.denymerge one?

That's because you were looking at the old config, before we switched
to using the current git-hooks.

binutils-gdb.git has the current config:

| [hooks]
|         from-domain = sourceware.org
|         mailinglist = /git/binutils-gdb.git/hooks-bin/email_to.py
|
|         # We do not want to force a maximum line length in commit
|         # revision logs, as they get in the way of copy-pasting
|         # debugging session, error messages, logs, etc.
|         max-rh-line-length = 0
|
|         # Reject merge commits on a certain number of branches:
|         #  - on master: We request that people rebase their changes
|         #    before pushing instead (merge commits tend to confuse
|         #    git newcommers).
|         #  - on GDB release branches: There is a high risk that a merge
|         #    commit is a merge from master into the branch, which would
|         #    bring a lot more than what the user probably meant to push.
|         #    Request that the user cherry-pick his changes.
|         reject-merge-commits = refs/heads/master,refs/heads/gdb-.*
|
|         # The style checker, applied to the contents of each file being
|         # modified.
|         style-checker = /git/binutils-gdb.git/hooks-bin/style_checker
|
|         # The URL where we can inspect the commit, inserted in the commit
|         # notification email, and also copy sent to the file-commit-cmd.
|         commit-url = "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=%(rev)s"
| 
|         # Do not send emails for the following branches (unofficial
|         # third-party branches).
|         no-emails = refs/heads/users/.*
|
|         # Send a copy to bugzilla if a commit has a PR number in it.
|         file-commit-cmd = "/sourceware/infra/bin/email-to-bugzilla -G 'gdb binutils'"
|         # The script that calls the irker (IRC notification of new
|         # commits).
|         post-receive-hook = /git/binutils-gdb.git/hooks-bin/post-receive

You might not need all of that. The binutils-gdb.git is a fairly
complex example, as you can see.

You can play with the hooks and their configuration, by using
a dummy repository, located on your machine, and configured to
send the commit emails to yourself. This would give you an opportunity
to get familiar with them prior to deploying to the official repository.

-- 
Joel