On Thu, Jun 19, 2008 at 10:21:56AM +0200, Karl Hasselstr=F6m <kha@treskal.c=
om> wrote:
quoted text
> 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.
>=20
> (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.)