On 2008-06-18 14:03:51 +0100, Catalin Marinas wrote:
> 2008/6/17 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > 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.)
> 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.)
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
