On Thu, Jun 19, 2008 at 11:19:03AM +0200, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > 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.) I may miss something, but you have (at least) two options to store "patches". You can store them as a blob, make a tree of them and make a commit in the log branch point to the tree. This one has the advantage of being able to do a 'git log' on a particular patch of the patch set. The other one is to create n+1 trees (and commits, where the first commit has no parent) for n patches, and point to the last commit from the log branch.
Attachment:
pgp7VRAZQu4vT.pgp
Description: PGP signature
