Re: git-rerere observations and feature suggestions

From: Miklos Vajna <vmiklos@frugalware.org>
Date: Jun 19, 2008, 10:06 UTC
Message-ID: <20080619100637.GO29404@genesis.frugalware.org>
In-Reply-To: <20080619091903.GA14415@diana.vm.bytemark.co.uk>

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

Show 12 quoted lines

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