Christian Couder <christian.couder@xxxxxxxxx> writes: > +--filter=<filter-spec>:: > + Remove objects matching the filter specification from the > + resulting packfile and put them into a separate packfile. Note > + that objects used in the working directory are not filtered > + out. So for the split to fully work, it's best to perform it > + in a bare repo and to use the `-a` and `-d` options along with > + this option. See linkgit:git-rev-list[1] for valid > + `<filter-spec>` forms. After running the command with this option once, we will have two packfiles, one with objects that match and the other with objects that do not match the filter spec. Then what is the next step for the user of this feature? Moving the former to a slower storage was cited as a motivation for the feature, but can the user tell which one of these two packfiles is the one that consists of the filtered out objects? If there is no mechansim to do so, shouldn't we have one to make this feature more usable? At the level of "pack-objects" command, we report the new packfiles so that the user does not have to take "ls .git/objects/pack" before and after the operation to compare and learn which ones are new. I do not think "repack" that is a Porcelain should do such a reporting on its standard output, but that means either the feature should probably be done at the plumbing level (i.e. "pack-objects"), or the marking of the new packfiles needs to be done in a way that tools can later find them out, e.g. on the filesystem, similar to the way ".keep" marker tells which ones are not to be repacked, etc.
