My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
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
Status:  Duplicate
Merged:  issue 71
Owner:  ----
Closed:  Jun 23

Sign in to add a comment
Reported by, May 27, 2011
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/ 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
We're trying to address this through direct Gerrit support for what 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
Project Member #4
(No comment was entered for this change.)
Status: Duplicate
Mergedinto: 71
Sign in to add a comment

Powered by Google Project Hosting