[RFC] Solution for duplicated or false review/bug notifications

[Boudewijn Rempt]

On Thursday 01 November 2012 Nov, Jaroslaw Staniek wrote:

> tl;dr
> I propose to treat public KDE git branches (for all repos) having
> '-work' suffix in a special way: ignore REVIEW and BUG/CCBUG lines.
> When commit hits a public KDE git branch without -work suffix, current
> behaviour is preserved.

Hm...

> 
> ** The problem:
> Whenever commits are pushed from work branches and they contain
> merged/cherry-picked commits (from other developers) with REVIEW:
> line, we're getting repeating notes on rb and emails: "This review has
> been submitted with commit xxxxxxxxx by yyyyyyyy to branch zzzzz."
> I think the hook shall not generate duplicated reviews like this.

But for cherry-picked commits to branches, I want to see those. And when I update my repo, then I definitely don't want to see any commits in your rebased work branch. I don't want to download them, I don't think the git hooks are the problem: the problem is those fake commits you create when rebasing a branch after merging before pushing the merge commit.

You just shouldn't do that. If you merge master into a branch, push that commit before someone else commits to that branch. If you cannot, start your merge anew from that commit.

If I pull from the shared repo, I don't want to see those commits.

> Moreover the issue propagates to bugs.kde.org: multiple commits with
> the same BUG: or CCBUG: line also cause multiple events registered
> within the bug entry, and multiple email notifications.

For cherry-picks, it's fine to see what happened. Just don't push a rebased merge. If you don't do that, the commit hooks don't need to be updated. I don't mind the hooks checking something in the branch name -- but I am not going to support changing the current calligra conventions for naming work branches. Just work in a way that suits the tools -- don't fight the way the tools work.

It's not the commit hooks for reviewboard, mailing lists or bugzilla that are the problem. It's the rebased, fake, wrong commits that get pushed. Don't push after rebasing a work branch after merging.
-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl