Re: auto-packing on kernel.org? please?

On 22/11/05, Junio C Hamano [off-list ref] wrote:

Catalin Marinas [off-list ref] writes:

quoted

What I meant is any object whose exact reference is found in
refs/patches (not reachable via refs/patches), even if it is reachable
from refs/heads.

do you mean you
keep blobs and trees in refs/patches, or "exactly found in
refs/patches" imply "commits in refs/patches and trees and blobs
reachable from it"?  If the latter I think it amounts to the
same thing.  If some of the blobs are shared with what is
reachable from refs/heads or refs/tags I would presume you would
want to pack them.

Each patch needs to have 2 commit and 2 tree objects (with the
corresponding blobs). I now understand where the problem appears. Most
of the blobs should actually be packed since they are part of the base
of the stack.

Since refs/heads files always point to the top of the stack, the
applied patches (the corresponding objects) would be automatically
packed. The alternative would be to only pack the objects reachable
from refs/bases but that's really StGIT-specific.

Other algorithm would be to avoid packing objects reachable from
refs/patches but not reachable from refs/bases but this would probably
complicate GIT.

And the "volatile" idea may be a good way of doing this.
Perhaps "git repack --volatile <glob>" to name paths under
.git/refs to mark things not to be packed, with a per-repository
configuration item to give default 'volatile' patterns?  I could
use it when packing my repository to exclude things that are
only reachable from "pu" branch.

After I eventually understood what you meant, the above would still
include the already applied StGIT patches since they are reachable via
HEAD. Maybe StGIT could avoid modifying refs/heads but I think it
would lose some benefits.

--
Catalin