When closing a change by push, the ref update to advance the branch
(ReceiveCommits.java:574) happens before closing the changes
(ReceiveCommits.java:614). This means in the event of some kinds of
database failures, a change might be merged into the destination
branch but never marked merged, *and* the actual commit SHA-1 that was
pushed might differ from any existing patch set.
Without doing a full walk of history, we have no easy way of
recovering from this situation only by inspecting the repo on the
server. The only way to detect a commit matching the change that
should have been inserted as a new patch set would be to inspect the
Change-Id footers, but we wouldn't know how far back in history to
walk. (This is additionally complicated by the fact that a commit with
the same Change-Id may have been merged in from a different branch.)
Fortunately, in the case we're talking about here, the end user should
have some record of the SHA-1 they're looking for, since they
previously ran "git push" on that SHA-1. So, this change provides a
new field in FixInput, expectMergedAs, to provide that SHA-1 and check
that it was actually the SHA-1 the change was merged as. In the event
that there is no patch set for the change at that SHA-1, one is
created.
Since the check would be potentially too expensive to do without
providing this SHA-1, it is only activated when this fix field is
provided.
Change-Id: Ie96633aae39d22694b2e6add072ce9ee82f1e30b
a828fedfba