Re: [StGit PATCH 03/14] Write to a stack log when stack is modified
- From
- Catalin Marinas <catalin.marinas@gmail.com>
- Date
- Jun 17, 2008, 10:24 UTC
- Message-ID
- <b0943d9e0806170324j12605a55m41b582ad09925cce@mail.gmail.com>
- In-Reply-To
- <20080612053424.23549.64457.stgit@yoghurt>
Hi Karl,
There are some comments below but I think I haven't fully understood this.
2008/6/12 Karl Hasselström <kha@treskal.com>:
Show 7 quoted lines
> Create a log branch (called <branchname>.stgit) for each StGit branch, > and write to it whenever the stack is modified. > > Commands using the new infrastructure write to the log when they > commit a transaction. Commands using the old infrastructure get a log > entry write written for them when they exit, unless they explicitly > ask for this not to happen.
I was more thinking for this to be the default for backwards API compatibility.
> class _Directory(object): > - def __init__(self, needs_current_series = True): > + def __init__(self, needs_current_series = True, log = True):
i.e. we make log = False here by default.
> --- /dev/null > +++ b/stgit/lib/log.py > @@ -0,0 +1,254 @@ > +r"""This module contains functions and classes for manipulating
Why does this start with an 'r'? I thought this is for regular expressions.
Show 5 quoted lines
> +A stack log is a git branch. Each commit contains the complete state
> +of the stack at the moment it was written; the most recent commit has
> +the most recent state.
> +
> +For a branch C{I{foo}}, the stack log is stored in C{I{foo}.stgit}.The main question. Is this history preserved after a git-gc?
Show 30 quoted lines
> +Tree
> +----
> +
> +The top-level tree object has the following entries:
> +
> + - C{version}: a blob containing the string "C{5\n}".
> +
> + - C{head}: a blob containing the ASCII hex sha1 of the current HEAD,
> + followed by a newline.
> +
> + - C{applied}, C{unapplied}: blobs containing one line for each
> + applied or unapplied patch, in order. Each line consists of
> +
> + - the ASCII hex sha1 of the patch's commit object,
> +
> + - a space, and
> +
> + - the patch's name.
> +
> + - C{patches}: a tree containing one subtree for each patch, named
> + after that patch. Each such subtree contains:
> +
> + - C{a}, C{b}: the patch's I{bottom} and I{top} trees.
> +
> + - C{info}: a blob containing::
> +
> + Author: <author name and e-mail>
> + Date: <patch timestamp>
> +
> + <commit message>I might not fully understand this but can we not store just the commit object if the patch, which would have the bottom/top information.
Show 13 quoted lines
> +Simplified log
> +--------------
> +
> +The simplified log looks exactly like the normal, or I{full}, log,
> +except for the following:
> +
> + - Instead of having a tree per patch in the C{patches} subtree, it
> + has a blob per patch. This blob contains::
> +
> + Bottom: <sha1 of patch's bottom tree>
> + Top: <sha1 of patch's top tree>
> + Author: <author name and e-mail>
> + Date: <patch timestamp>Can we not point to the original commit corresponding to the patch? It already has this information.
Show 6 quoted lines
> + > + <commit message> > + > + --- > + > + <patch's diff>
What is the patch's diff here? Cannot it be determined from the trees?
> +The simplified log contains no information not in the full log; its > +purpose is ease of visualization."""
Ah, OK. But I think it would be more useful to see the diff between subsequent revisions of a stack rather than the full patch diff.
Thanks.
-- Catalin