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

[Catalin Marinas <catalin.marinas@gmail.com>]

On 22/11/05, Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> > 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