Re: [PATCH v4 2/3] repack: add --filter=<filter-spec> option

Patrick Steinhardt [off-list ref] writes:

While this is a nice safeguard, I wonder whether it is sufficient.
Suppose you for example have a non-bare repository that already has
blobs checked out that would become removed by the filtering repack --
does Git handle this situation gracefully?

A quick check seems to indicate that it does. But not quite as well as
I'd have hoped: when I switch to a detached HEAD with an arbitrary
commit and then execute `git repack --filter=blob:none` then it also
removes blobs that are referenced by the currently checked-out commit.
This may or may not be what the user is asking for, but I'd rather lean
towards this behaviour being surprising.

Hmph, the user asked not to have blobs that came from remote locally
and instead refetch them from the promisor on-demand, so I would
expect some pruning to happen (I am not a lazy-clone user, though).

As long as we do the pruning sensibly, that is.

Unless you are always following somebody else without doing any work
on your own, you are likely to have objects that exist only locally
and nowhere else.  It would be unexpected and surprising, if we lost
them only because they are of type 'blob' and because there is a
promisor remote configured.

Even if that is documented, that would be an unacceptable foot-gun
misfeature.  It is not just a local repository corruption that can
be recovered by cloning from elsewhere.  We are looking at lost
work that cannot be recovered.

I wonder if this topic can be salvaged by making it less aggressive
in pruning, perhaps by traversing from the tips of remote-tracking
branches of the promisor remote to identify which blobs can safely
be pruned (by definition, promisor remote cannot lose objects that
it once published, or its cloners will immediately have corrupt
repositories).  That may turn this from a misfeature into a feature.

Thanks.