tree dc1b217f102368bdedc278047e3a56772aa01bb7
parent 2e8b8e83e2d4a477a6a60ac41bafe9607876ce67
author Jonathan Nieder <jrn@google.com> 1446601506 -0800
committer Jonathan Nieder <jrn@google.com> 1446601506 -0800

Include ancestors of reused bitmap commits in reuse bitmap again

Until 320a4142 (Update bitmap selection throttling to fully span
active branches, 2015-10-20), setupTipCommitBitmaps contained code
along the following lines:

	for (PackBitmapIndexRemapper.Entry entry : bitmapRemapper) {
		if (!reuse(entry))
			continue;
		RevCommit rc = (RevCommit) rw.peel(rw.parseAny(entry));

		reuseCommits.add(new BitmapCommit(rc));
		EWAHCompressedBitmap bitmap =
			remap.ofObjectType(remap.getBitmap(rc), OBJ_COMMIT);
		writeBitmaps.addBitmap(rc, bitmap, 0);
		reuse.add(rc, OBJ_COMMIT);
	}
	writeBitmaps.clearBitmaps();	// Remove temporary bitmaps

This loop OR-ed together bitmaps for commits whose bitmaps would be
reused.  A subtle point is the use of the add() method, which ORs in a
bitmap from the BitmapIndex when it exists and falls back to OR-ing in
a single bit when that bitmap does not exist in the BitmapIndex.

Commit 320a4142 removed the addBitmap step, so the bitmap does not
exist in the BitmapIndex and the fallback behavior is triggered.

Simplify and restore the intended behavior by avoiding use of the
subtle use of the add() method --- use or() directly instead.

Change-Id: I30844134bfde0cbabdfaab884c84b9809dd8bdb8