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:
@@ -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;
|
||||
|
||||
Reference in New Issue
Block a user