Re: [StGit PATCH 03/14] Write to a stack log when stack is modified

From: Karl Hasselström <kha@treskal.com>
Date: Jun 18, 2008, 14:36 UTC
Message-ID: <20080618143633.GB30540@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0806180603h59187f7epc5014f36d070cec7@mail.gmail.com>

On 2008-06-18 14:03:51 +0100, Catalin Marinas wrote:

Show 6 quoted lines

> 2008/6/17 Karl Hasselström <kha@treskal.com>:
>
> > The log actually _contains_ those trees, so there is no problem.
>
> OK, I begin to understand. It is a generic solution for storing
> metadata

I don't know about "generic" -- it's made specifically for storing an StGit stack. You could certainly store just about anything in a git tree, but that's also true for a git commit message ...

> but IMHO it is too overweight when we only need a list of applied
> and unapplied files (we can remove hidden) that could be easily
> stored in a commit log.

Do you mean remove hidden patches from StGit altogether, or just not store them in the log?

> It would be useful to run a quick benchmark with many (hundreds) of
> patches and compare it with no logging variant (or the current patch
> logging, which isn't as advanced).

Will do, as soon as I've done some basic optimization. (A simple "dirty" flag on each patch will enable us to only write out the log for the patches that have actually changed, and reuse the rest from the previous log entry.)

Show 8 quoted lines

> Could we not make this (much) simpler? I.e. <branch>.stgit is a
> commit object whose tree is <branch>^{tree} and the message contains
> the command followed by list of patches in the form "<commit>
> <patch>"? This commit can have two parents - the previous
> <branch>.stgit and current <branch> head. All the patches are
> referred via the <branch> head or the previous <branch> heads if
> unapplied (assuming that when a patch is created it is first applied
> and then popped, maybe this needs a bit of thinking).

I considered a scheme much like this, but besides the problem with (the very few) patches that are created unapplied, it fails badly in a very important corner case: when you start logging in a pre-existing stack. A similar failure will occur if we ever build some sort of log pruning (without which the log will grow without limit).

I suppose it would be possible to special-case the very first log entry: let it have all patches as ancestors. But I don't really see this format as being simpler than the one I use now: all you've done, basically, is cram all the data into the commit message instead of storing it in the tree. (Benchmarking could certainly prove your design superior to mine, however.)

> This way, a diff between subsequent <branch>.stgit commits would
> show the tree changes. The 'stg log' command could be made to show
> differences in the commit messages.

Tree changes are only really useful for refresh. (More on this below.)

Show 8 quoted lines

> > If you have ideas for a better way to visualize this, I'm all
> > ears.
>
> The diff of diffs is generally useful but for 'refresh' logs, you
> can show the diff between the old top tree and the new one (the
> current patch log implementation does something like this but it
> doesn't show anything for commands like 'push' where a diff of diffs
> would be more appropriate).

The diff-of-diffs view is actually very useful for refresh as well. The diff of old and new top tree is useful only for refresh (but it _is_ useful -- I'm not arguing against it).

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