Re: gcc-cvs mails for personal/vendor branches for merge commits

[Iain Sandoe <idsandoe at googlemail dot com>]

Joel Brobecker <brobecker@adacore.com> wrote:

> > I think it's desirable for development that *happens on* the personal and
> > vendor branches to be visible in gcc-cvs - that is different from things
> > getting merged into them.
> >
> > Likewise for the refs/heads/devel/* development branches -
> > non-fast-forward pushes are not permitted there, but such branches can
> > expect to have lots of merges from master, and it's the actual development
> > taking place *on* the branches - the new commits - that is of interest to
> > see on gcc-cvs, not the merging of existing commits.
>
> Would it be sufficient to say that some branches would only
> trigger a summary email, but not individual commit emails?
> The downside is that you would not be getting the "diff" for
> commits that are really completely new. But on the other hand,
> it would fit better with the fact that user branches could have
> frequent re-basing, thus causing the same commit email being sent
> over and over at each rebase operation. It would also answer
> the issue of the number of emails being sent when people are doing
> a merge which brings in more commits than the max-emails number.

AFAIU, we have access to more fine-grained information; isn’t it possible
to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
(because a ‘new’ commit does not have the extra fields set up for merges
 and rebases).

For example, I’d like to know that user/fred has rebased the branch i’m
interested in but OTOH, would not find the per-commit mails useful (so a
summary there is good).

If a push contains a combination of things - new work, merged and rebased
commits - then there would have to be some way to react to split or aggregate
the messages / diffs per commit id.

Iain