Re: git-rerere observations and feature suggestions

From: Karl Hasselström <kha@treskal.com>
Date: Jun 19, 2008, 10:35 UTC
Message-ID: <20080619103521.GC14415@diana.vm.bytemark.co.uk>
In-Reply-To: <20080619100637.GO29404@genesis.frugalware.org>

On 2008-06-19 12:06:37 +0200, Miklos Vajna wrote:

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

If I don't store the pre or post tree in its entirety, I lose the ability to do patch application by three-way merge. (The current StGit design assumes that we can always make a three-way merge as a last resort when applying patches. Basically, StGit is just a fancy way to rebase.)

But yes, this is a viable idea. (Though once I have to store one of the trees, I believe it's actually simpler and cheaper to just store the other tree as well, instead of having to compute the diff and store that in a blob.)

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

There's actually no point in making more than one commit. A tree can easily hold a lot of sub-trees.

I have an existing implementation that stores the pre and post tree for each patch, plus some metadata (message, author). The issue with this format is that every time we write a new log entry (that is, for every StGit command), we have to call git multiple times in order to write several new trees and blobs.

StGit normally represents each patch by a commit object, so it should be faster to simply write a single new commit to the log that has some metadata in its commit message and just refers to all the patches' commit objects (by having them as parents). Which is why I was inquiring about the maximum number of parents of a commit object.

( Some background: At a given point in time, your StGit stack consists
  of a few applied patches, and a few unapplied patches. The applied
  patches are just a linear sequence of commits at the top of your
  current branch, so we can trivially save them all from the garbage
  collector by making the stack top a parent of our log commit. The
  unapplied patches, however, are commits that are not reachable from
  the stack top -- they can be "pushed" onto the stack by rebasing, at
  which point they become applied, but until then we can't make any
  assumptions about them being ancestors of anything. So a log commit
  potentially has to have _every_ unapplied patch as a parent. (If we
  know that the commit of an unapplied patch used to be applied, we
  know that it's reachable from previous log commits, but we don't
  always know that.) )

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle