Re: [RFC] Add --create-cache to repack

From: Shawn Pearce <spearce@spearce.org>
Date: Jan 28, 2011, 18:22 UTC
Message-ID: <AANLkTi=Mu+tP7V2wWq9Fr3RVmdWhG7gGhj=LWLSqerZ_@mail.gmail.com>
In-Reply-To: <4D42E1E3.4060808@viscovery.net>

On Fri, Jan 28, 2011 at 07:33, Johannes Sixt <j.sixt@viscovery.net> wrote:

Show 15 quoted lines

> Am 1/28/2011 15:37, schrieb Shawn Pearce:
>> A simple fix is to use --heads --tags by default like I do here, but
>> make the actual parameters we feed to rev-list configurable.  A
>> repository owner could select only the master branch as input to
>> rev-list, making it less likely the topic branches would be
>> considered.  Unfortunately that requires direct access to the
>> repository.  It fails for a site like GitHub, where you don't manage
>> the repository at all.
>
> Let's define a ref hierarchy, refs/cache-pack, that names the cache pack
> tips. A cache pack would be generated for each ref found in that
> hierarchy. Then these commits are under user control even on github,
> because you can just push the refs. Junio would perhaps choose a release
> tag, and corresponding commits in the man and html histories. The choice
> would not be completely automatic, though.

This is a good idea.  Perhaps we go slightly further and say:

  refs/cache-pack/name-without-slash

    This packs into its own pack file, as a single tip.

  refs/cache-pack/group/a
  refs/cache-pack/group/b

   These pack into a pack file together.

If you have direct repository access, you can also just make one of these a symbolic reference to a branch, e.g. refs/heads/master, and then periodic `git repack --create-cache` invocations would pick up the latest point.

-- 
Shawn.