Flushing is already done automatically at the right time by the
BatchUpdate implementations, and the RevWalk provided to callers can
already read unflushed objects. A BatchUpdateOp implementation calling
flush on the inserter is doing something wrong, and flushing too much
can seriously impact DFS performance when it happens in a loop.
Make flushing (and closing) a no-op rather than slapping implementors'
wrists by throwing an exception. Even if the implementor is well-
intentioned, we can't guarantee that all downstream library functions
are going to know not to flush their inserters. For example, JGit's
Merger used to be aggressive about flushing until I fixed it[1]. This
was the most glaring example, but I would be utterly unsurprised to find
more.
Also don't use InMemoryInserter for this purpose, as it actually flushes
too little. The purpose of that class is to avoid writing a pack to DFS
when the internal buffer in DfsInserter exceeds some limit, but in
BatchUpdate, it's fine to write out an intermediate pack in this case,
we don't have to buffer the whole thing in memory.
[1] https://git.eclipse.org/r/12504
Change-Id: I2b139e50af213c4b683c25d30b190bc547304f72
3915d7baa1