First, let me apologize for the tons of notification emails that the commits@ list has received recently due to my changes - I’m new to the git workflow at Apache, and it looks like I made a few missteps…
Still, I think there’s some room for improvement to the current notification model, so that it accommodates for work in progress commits, and most importantly occasional merging / rebasing from other branches:
* first, Shalin and I have used a ‘feature/metrics’ branch. As David Smiley kindly pointed out this branch doesn’t follow the ‘lucene-‘ or ‘solr-‘ naming scheme so the git bot didn’t know to suppress the notifications on commits there. This should be fixed once INFRA-13133 is resolved (and probably a note should be added to this effect in the git guide for committers),
* but even for a branch that follows this naming (jira/solr-9854) merging from master produced as many emails as there were commits between branches. Branching is a low cost operation in git (unlike in svn), so creating branches for even short-term work is attractive because it exposes work in progress to others and lets them collaborate. Longer-lived branches need occasional merging / rebasing so that they are reasonably up to date with master, but now each time this happens it will produce an avalanche of emails… The alternative would be to always merge —squash from master to a feature branch, so that it creates a single commit, but then it’s harder to merge it back and to track changes from master that may have affected your work.
So, I don’t think this level of detail is useful for work in progress branches. Is there any way for the bot to eg. combine notifications from these branches into a single email, a la ‘git diff —stat’ ?