> > My main question is: we can get the same list of objects (in the form of > > tree objects) if we fetch with "blob:none" filter. Admittedly, we will > > get extra data (file names, etc.) - if the extra bandwidth saving is > > necessary, this should be called out. (And some of the savings will be > > offset by the fact that we will actually need some of those tree > > objects.) > That's a very good point. The data the first request gives us is > basically the tree objects minus file names and modes. So I think a > better feature to implement would be combining of multiple filters. > That way, the client can combine "tree:<some small number>" and > "blob:none" and basically get an "enumeration" of available objects. To get an enumeration of available objects, don't you need to use only "blob:none"? Combining filters (once that's implemented) will get all objects only up to a certain depth. Combining "tree:<n>" and "blob:none" would allow us to reduce the number of trees transmitted, but I would imagine that the savings would be significant only for very large repositories. Do you have a specific use case in mind that isn't solved by "blob:none"?
