Be more consistent about object ids used in ref operation validation

In CreateBranch, a RefUpdate is created with expectedOldObjectId set
but not oldObjectId. In DeleteRef, none of expectedOldObjectId,
oldObjectId, and newObjectId is set.

As a result, when RefOperationValidators uses oldObjectId and
newObjectId to create a ReceiveCommand, they can be null, resulting in
NullPointerException when a listener dereferences them.

So use expectedOldObjectId instead of oldObjectId in
RefOperationValidators. Before a ref update has been performed, only
the former is meant to be set.

In DeleteRef, set the expectedOldObjectId and the newObjectId (which
is zero). This way, in RefOperationValidators we know both values
will always be set.

Bug: Issue 5817
Helped-By: Jonathan Nieder <jrn@google.com>
Change-Id: If1f3a6179fa789077731a16e4b731227a73be7f2
This commit is contained in:
David Pursehouse
2017-03-20 09:07:44 +09:00
parent d786b5cf79
commit fb9b741a5a
2 changed files with 5 additions and 1 deletions

View File

@@ -39,7 +39,7 @@ public class RefOperationValidators {
public static ReceiveCommand getCommand(RefUpdate update, ReceiveCommand.Type type) {
return new ReceiveCommand(
update.getOldObjectId(), update.getNewObjectId(), update.getName(), type);
update.getExpectedOldObjectId(), update.getNewObjectId(), update.getName(), type);
}
private final RefReceivedEvent event;