Re: git-rerere observations and feature suggestions

From: Karl Hasselström <kha@treskal.com>
Date: Jun 19, 2008, 09:19 UTC
Message-ID: <20080619091903.GA14415@diana.vm.bytemark.co.uk>
In-Reply-To: <20080619083356.GN29404@genesis.frugalware.org>

On 2008-06-19 10:33:56 +0200, Miklos Vajna wrote:

Show 35 quoted lines

> On Thu, Jun 19, 2008 at 10:21:56AM +0200, Karl Hasselström
> <kha@treskal.com> wrote:
>
> > Catalin and I are tossing ideas around for how to represent the
> > history of an StGit patch stack (using a git commit for each log
> > entry). One complication is that we have to keep references to all
> > unapplied patches so that gc will leave them alone (and so that
> > they will get carried along during a pull, in the future). And the
> > number of unapplied patches is potentially large, so I thought
> > we'd be going to have to make a tree of "merge" commits to connect
> > them all up.
> >
> > (What we'd really like, of course, is a way to refer to a set of
> > commits such that they are guaranteed to be reachable (in the gc
> > and pull sense), but not considered "parents".)
>
> I had a similar problem in git/vmiklos.git on repo.or.cz, while
> working on builtin-rebase: I squash several patches using rebase -i
> before sending a series, but it's nice to have the old long list of
> small patches in case I would need them later.
>
> What I did is to have a rebase-history branch: each commit in it is
> an octopus merge:
>
> - The first parent is the previous rebase-history ref
>
> - The second is the old HEAD
>
> - The third is the new HEAD
>
> This way I can use git rebase -i without worrying about loosing
> history, even if reflogs are not shared among machines.
>
> (It may or may not be a good idea to do something like this in
> StGit, I just though I share this idea here.)

What you're describing is pretty much what we're thinking about doing -- have a log branch where each commit contains enough metadata to recreate the complete patch stack state at that point in time, and has all the parents it needs to be safe from gc.

The particular problem I'm asking about here is that due to StGit's
concept of "unapplied" patches that are per definition not reachable
from the current branch head, a given log entry might have to keep an
unbounded number of commits from being gc'ed. Thus my question about
what would blow up if we were to make a commit with 50 parents. Or
100. Or 1000, if our users are crazy enough. (The alternative being,
of course, to make a tree of octopuses with a fixed maximum fan-out.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle