Re: git-rerere observations and feature suggestions

From: Miklos Vajna <vmiklos@frugalware.org>
Date: Jun 19, 2008, 08:33 UTC
Message-ID: <20080619083356.GN29404@genesis.frugalware.org>
In-Reply-To: <20080619082156.GB12727@diana.vm.bytemark.co.uk>

On Thu, Jun 19, 2008 at 10:21:56AM +0200, Karl Hasselström <kha@treskal.com> wrote:

Show 11 quoted lines

> 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.)