Re: [PATCH v2 5/8] repack: add `--filter=<filter-spec>` option

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> 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.