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.
"
