| Issue 985: | updates with empty deltas should not create new patchSets | |
| 13 people starred this issue and may be notified of changes. | Back to list |
when one rebases a commit but nothing really changes in it (except the sha1s), then pushing it to gerrit should not create a new patchSet. instead, only a separate version field should be updated. this would cleanly solve the problem that the contrib/trivial_rebase.py script tries to address. it would save space, useless notifications, effort to check that really nothing changed, computing power from some validation bots, and probably more.
May 27, 2011
Project Member
#1
nas...@codeaurora.org
May 27, 2011
yes, i know that a rebase can change integration results. that's why i said _some_ bots. anyway, let's approach this differently: there are comments which pertain to the actual diff (e.g., the code review) and comments which pertain to the result of applying the diff (e.g., build/test results). the former should "survive" a trivial rebase, while the latter should not. consequently, each push does have to create a new patchSet after all, but comments/scores should be tagged as "inheritable by trivial rebases" or not (automatically preset, depending on the source. criterion could be a flag in the user profile - reviewer (human, coding style bot, etc.) or tester (human, compile+autotest bot, etc.). yes, i think this is a duplicate of issue 71 (i didn't find it because i didn't try "identical". stupid me). i'll just note that the patch-id is not sufficient - i want it to be whitespace-sensitive and also include the commit message.
Jun 20, 2014
somebody feels like finally closing this as a duplicate?
Jun 23, 2014
(No comment was entered for this change.)
Status:
Duplicate
Mergedinto: 71 |
|
| ► Sign in to add a comment |