Re: RFC: git config and scripts

[Joel Brobecker <brobecker@adacore.com>]

> This work consists of a few parts:
> 
> * A modified copy of git's sample "post-receive" script, which I've
>   hacked to be able to send email to multiple commit lists based on
>   which directories were modified, and to send email to bugzilla when a
>   PR is mentioned in a commit message.
> 
> * A modified copy of the loginfo script we use, with anything pertaining
>   to cvs removed, leaving just some bugzilla functionality.  I further
>   modified this to look in multiple products for a bug, when desired.
> 
> * The "src-email" file, some configury for src.git which tells
>   post-receive which directories correspond to which commit lists.
> 
> * The git "config" file for src.git.

Nice!

> About the last part -- there are various settings we could have for
> src.git.  A few to consider:
> 
> * I chose a relatively simple format for the commit email, and I kept
>   the format used for bugzilla the same.  The format I chose mentions
>   the commit's URL, plus the "--pretty" log output (SHA, author, date,
>   and commit message).

A pretty good first start to get us going!

At AdaCore, we needed to have individual emails for each commit
for internal reasons, and some of the reasons might actually
apply to us (someone pushing multiple commits solving multiple
PRs - would the email to bugzill cross-pollute the PRs?).
The implementation we came up with is fairly complex, and is
unfortunately difficult to share, because it depends on some
internal python modules we developed to tie all our internal
tools. And also there is the fact that it does not handle multiple
projects sharing the same repository. I think I can give access to
some of the code, even if I'm not super happy with it yet.

That's why I am happy starting with what you wrote, see how it feels,
before proposing anything.

For completeness, we original used an adaptation of the git hooks
used by GNOME, but I'd personally stay away from them. Really hard
to adapt and improve, I thought.

> * The appended config requires fast-forward pushes only.  In archer
>   we've relaxed this, since we like to be able to rebase, but not
>   everybody likes that.

I agree with that policy. If people want to do non-fast-forward changes
on branches shared with others, they can always host it themselves.
Alternatively, what we have done at AdaCore is allow rebasing on
all branches named "topic/*". We have a second mechanism that allows
us to configure repositories to accept rebasing on specific branches,
but I don't think we ever used it.


> * Other projects have "update" hooks to do things like reject merge
>   commits to master, or reject commits that introduce trailing
>   whitespace.

Some good ideas for our next rainy day... I'm not sure about
rejecting merges or not, but rejecting trailing whitespaces would
be helpful, I think. Ever since I adapted my editor to highlight
them, it's been bugging me :-).

-- 
Joel