Re: git-rerere observations and feature suggestions

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

On Thu, Jun 19, 2008 at 10:21:56AM +0200, Karl Hasselström
[off-list ref] wrote:

quoted

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