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

Iain Sandoe idsandoe@googlemail.com
Fri Jan 17 17:22:00 GMT 2020

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.


More information about the Gcc mailing list