Luigi Toscano wrote: > 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. >> >> ** 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. > >> [...] >> **What workflow is affected: >> Affected workflow that use integration with git.reviewboard.kde.org >> and/or bugs.kde.org is as follows: >> >> 1. Push a change without a REVIEW but optionally with BUG/CCBUG lines. >> Of course because we do not know the review number at the moment). >> Pushing to a public work branch is often needed if we expect someone >> will need/want to test the code. > > > So why not using a personal clone for this (publishing the work), and not > allowing notifications (if it is not the case) for personal clones, > instead of changing the rules for official repositories?
It's possible but while personal repos are useful, let's see what is introduced with them in our context: - for reviewboard I need to reference public project's repository, e.g. calligra; otherwise patches will get rejected reviewboard; so before submitting to review I need to create a copy of the commit within the official repo anyway - private repo adds another layer in the (already not trivial to explain) multiuser workflow: I need to create a copy of the commit in the official repo anyway since the personal repo is meant for use (r/w) by the owner (if I understand correctly) - private repos do not support email notification about the changes (hiding them was not requested by me) > Rebase on officially published repository is always bad. I don't think > officially allowing rebase on a subset (the -work ones) of public branches > is the proper way to do. This is not a part of the request. It's about behaviour of integration with rb and b.k.o, i.e. KDE-specific integration. When using cherry-picking. > For cherry-picking, there is not so much to do, as they are new commits. > Merged commits (not rebased), afaik, do not produce new notifications. That's true. Our discussion is based on the assumption that cherry-picking is valuable just like editing commits before picking them to other branches (e.g. split/squash) is. I am askimg my 'students' to commit early and often without a fear to their -work branches. Author of git explains it's jsut another tool which complements merges [https://lkml.org/lkml/2008/5/21/351]. But then multiple messages that contain the same REVIEW or BUG lines will exist in the repo, when some of them do not mean a review is submitted or a bug is resolved. So here's the proposal for addressing this (when needed) in advance - when picking a name for a new branch. There's different solution that addresses the problem of duplicated submissions (but not the unwanted premature submissions): It may be possible to block 'resolving' of already 'resolved' bug on b.k.o and submitting already 'submitted' review on rb by altering logics of these two sites. -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org Qt Certified Specialist | http://qt-project.org http://www.linkedin.com/in/jstaniek