From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Tue, 17 Jun 2008 10:24:53 GMT
Subject: Re: [StGit PATCH 03/14] Write to a stack log when stack is modified
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>:
> 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.

> +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?

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

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

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