On Thu, Feb 23, 2017 at 03:50:00PM -0800, Junio C Hamano wrote: > Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > > > Adding "--objects" works, and all existing tests pass, except for the > > potential performance issue and the side effect that even fetching a > > reachable blob no longer works. This is due to a possible bug where a > > call like "git rev-list --objects $tree ^master" (where $tree is the > > tree object corresponding to master) prints out objects ... > > The "reachable from this, excluding what is reachable from that" > notation was originally designed to work only on commits, and I > wouldn't be surprised if "$tree ^master" did not work as you expect > in the current implementation. > > I agree that ideally it shouldn't show anything, but I suspect that > it would make it very expensive if done naively---we'd end up having > to call mark_tree_uninteresting() for all uninteresting commits, not > just for the commits at the edge of the DAG as we do right now. Yes, it's super-expensive to do naively (like 40+ seconds of CPU on torvalds/linux). Bitmaps should generally make it tolerable, though there are corner cases (e.g., if a ref tip has to walk a bit to get to a bitmap; we try to put bitmaps near the ref tips, but when you have 50,000 tags it's hard to do). We've explored similar things at GitHub for doing reachability checks on all 40-hex lookups (because right now I can point you to .../git/git/commit/1234abcd and you see that object, even if it's only in _my_ fork and not reachable from git/git). -Peff