commit 9bad11795acfda02be644ff5ce1ab6eef4fe543f
author Dave Borowitz <dborowitz@google.com> Thu Apr 06 15:51:05 2017 -0400
committer Dave Borowitz <dborowitz@google.com> Fri Apr 07 11:56:59 2017 -0400
tree 2bb58eff5ea14ff9c1ef579232bfe94e4c93e31f
parent 17e262e92bef15db5767f16c6880333df1597b8c

Remove CommitValidators.Policy

Almost all callers are just switching between a single policy, e.g. the
default of GERRIT for ChangeInserter/PatchSetInserter, and no
validation. The internals of CommitValidators.Factory#create just called
one of the for* factory methods depending on the enum value; it's just
as readable to do this at the source.

Within ChangeInserter/PatchSetInserter, it's just as easy to represent
do/don't validate with a single boolean value. The interaction with
RebaseChangeOp is slightly nonobvious: it used a null enum field value
to mean don't override PatchSetInserter's default. Thus we need to
explicitly set the default of the boolean value to true. (Or use
tri-state Boolean, but boolean is more consistent with the rest of the
fields in this class.)

It's worth noting that forGerritCommits is always called from within a
BatchUpdateOp, which means we can later change its parameters to not
pass a full Repository instance. By contrast forReceiveCommits is only
called from ReceiveCommits, outside of the BatchUpdate, so it always has
a full Repository available. Splitting the factory methods up in this
way allows us to pass different arguments to the different paths.

Change-Id: I833b739f2c4ab4a65ea80382b1c147dd6adc1892