commit 0b3a8796aac444ba9f59e3901fd3b97ab9e3ec2c
author Dave Borowitz <dborowitz@google.com> Mon Feb 08 09:19:10 2016 -0500
committer Dave Borowitz <dborowitz@google.com> Tue Feb 09 10:05:58 2016 -0500
tree a9909674c7402504f57a207abd13ed1225965534
parent 2878bb5778bfb8809df093696d2f634cf58aeead

Remove "no changes made" error case

This is the error that occurs during push when the only difference
between a new commit and the previous patch set of the change is the
committer. This can happen sometimes after a series of rebases that
don't behave exactly as the user expected. Typically, the user doesn't
know how they got into this state, and they don't know how to get out
of it. (Getting out of it requires splicing in the old commit SHA-1--
or maybe many old commit SHA-1s--in the interactive rebase editor,
which requires more familiarity with interactive rebasing than we
usually expect even from Gerrit users.)

The benefits of keeping this error message are:
 a. It prevents extraneous patch sets.
 b. It avoids the original committer on the change from having to
    fetch and rebase.
 c. It doesn't step on approvals of previous patch sets.

I would argue that the cognitive burden of creating a few extra patch
sets here and there is far outweighed by the minutes or hours of
confusion caused when a user actually puts themselves in this state.
This includes the burden both on the committer doing th push of an
identical patch set, and the original committer of the previous patch
set as in (b).

In many cases the committer identity doesn't change, only the
committer timestamp, in which case the user already has the new copy
of their commit. In the case where it differs, this is really no
different from any other time two committers collaborate on the same
change. Plus, when a user encounters this error, there is a good
chance they will try to recover by pushing a new patch set with a
whitespace change or something, in which case they end up with two
extraneous patch sets and the original committer still has to fetch
and rebase.

Regarding (c), this benefit carried more weight before we implemented
approval copying. Now, with the default configuration of copying
Code-Review on trivial rebase and Verified on no code change, the
extraneous patch sets should have most of their approvals copied, so
they don't interrupt the workflow as much.

Finally, note that there is no security/permissions argument for
keeping this error due to one committer "taking over" commitership of
the change commit from someone else. Any user with Forge Committer
permission can already create a patch set that is identical to a
previous patch set owned by someone else, simply by pushing a
non-identical patch set in between.

In conclusion, the "no changes made" error is no longer worth the
confusion caused, so convert the error into an informational warning
as in other cases.

Bug: Issue 1867
Change-Id: I7ecdd1ae29a7b920288639d034c21fc1ce0edb99