On Wed, Jul 5, 2023 at 8:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. I think commands like `git verify-pack -v ...` can already tell a bit about the content of a packfile. Also this patch series adds `test-tool find-pack` which can help too. It could maybe be converted into a new `git verify-pack --find-pack` option if users want it. Then, as you later found out, there is the --filter-to=<dir> option added later by this series. To clarify this, I have added the following to the commit message in the version 3 I just sent: " It's possible to find which new packfile contains the filtered out objects using one of the following: - `git verify-pack -v ...`, - `test-tool find-pack ...`, which a previous commit added, - `--filter-to=<dir>`, which a following commit will add to specify where the pack containing the filtered out objects will be. "