On Thu, Jun 19, 2008 at 10:21:56AM +0200, Karl Hasselström <kha@xxxxxxxxxxx> 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.)
Attachment:
pgpsu8xuebMct.pgp
Description: PGP signature
