On Wed, Jan 27, 2021 at 05:57:21PM -0500, Taylor Blau wrote: > > You can find that out by generating a list of objects, getting their > > sizes from cat-file, and then summing them, like: > > > > git rev-list --objects main..branch > > cut -d' ' -f1 | > > I suspect that this is from the original commit message that you wrote a > half-decade ago. Not that it really means much, but you could shave one > process off of this example by passing '--no-object-names' to 'git > rev-list'. That, plus my muscle memory to do the cut. We should probably model the better form here, and use it in the test, though (not worth a re-roll on its own, but it looks like there are a few other minor bits). > > - not counting up all reachable objects (i.e., requiring --objects for > > this output, and omitting it just counts up commits). This could be > > handled in the bitmap case with some extra code (OR-ing with the > > type bitmaps). > > > > But after 5 years of this patch, I've never wanted that once. The > > disk usage of just some of the objects isn't really that useful (and > > of course you can still get it by piping to cat-file). > > Yeah. I think it's trivial to support it, but I'm in favor of a simpler > interface. > > That said, I worry about painting ourselves into a corner if the default > implies --objects. If we wanted to change that, I'm pretty sure you'd > have to write a rule that says "imply objects, unless --tags, --blobs or > etc. are specified, and then only do that". > > Maybe we'll never have to address that, but it's worth thinking about > before committing to implying '--objects'. Yeah, the one thing that gives me pause is that it would be hard to undo later. I didn't write the code to handle it in the bitmap case, but I don't think it would be _too_ bad. It is slightly annoying for the all-objects case, because the existing code isn't set up well to iterate either a specific type, or all types. > I have no comments on the patch itself, which looks fine to me (and I > have seen over and over again as it seems to regularly cause conflicts > when merging new releases into GitHub's fork :-)). You are exposing my ulterior motive. :) -Peff
