gcc-cvs mails for personal/vendor branches for merge commits
Fri Jan 17 17:22:00 GMT 2020
Joel Brobecker <firstname.lastname@example.org> 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
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