|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
We're trying to address this through direct Gerrit support for what trivial_rebase.py is currently doing. I think last week we got patch-id support into JGit and now we need to teach Gerrit how to use that to compare two different patch sets. I think we do still want two patchsets for this case, but I think I understand why you might not. As for some of your arguments about checking when things change, computing power, etc; those aren't necessarily valid. You can have a trivial rebase where it worked before the rebase and didn't afterwards. Testing on both sides is necessary. How do you feel about issue 71 ? I think that's the path we'd like to go first (or at least I would).
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.)
|► Sign in to add a comment|