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

["Catalin Marinas" <catalin.marinas@gmail.com>]

2008/6/17 Karl Hasselström <kha@treskal.com>:
> On 2008-06-17 11:24:53 +0100, Catalin Marinas wrote:
>> 2008/6/12 Karl Hasselström <kha@treskal.com>:
>> >  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.
>
> I might not have understood precisely what you meant; but I don't
> think API backwards compatibilty should be an issue here? I simply fix
> all callers. If log should default to true or false is immaterial --
> it just means some extra text in one or the other of two equally
> common cases.

Not an issue, I just favour the existing one when the two cases are
almost equal.

>> > --- /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.
>
> "r" in front of a string literal means "raw" (or some such). Escape
> sequences aren't recognized inside a raw string -- e.g., r'\n' ==
> '\\n'. They are useful when you have to write strings with embedded
> backslashes, such as regexes -- or this string, which has \n in it.

Thanks, I didn't know this.

>> > +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?
>
> Yes. It's stored in a regular git branch. (The design is such that it
> should even be possible to pull a stack log from another repository
> and _still_ get everything you need.)

But how are the patches recreated when undoing (the
refs/patches/<branch>/* files)? Using the Bottom/Top tree ids that a
patch had in the past? Are these trees still present after a git-gc?

>> > +  - 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.
>
> You can't store a commit object in a tree. (Well, with submodules you
> can, but said commit object isn't protected from gc and won't be
> included when pulling.) The idea with this format is that with the two
> trees and the info file, you can recreate the patch's commit -- not
> exactly, but close enough as makes no difference.

What I meant is the SHA1 value of the patch commit instead of
Bottom/Top, Author and Date. The corresponding commit object has all
this information.

>> > +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.
>
> Have you tried looking at a patch stack log (in gitk, say)?

I tried "gitk master.stgit" and got scared :-)

> That is, "stg log -g" in this patch series.

This is more readable.

> It shows you diffs between
> subsequent revisions of the simplified log. I'm sure it's far from
> perfect, but I think it's actually quite useful.

It is useful, though it might take a bit of time to get used to it. It
might also be a bit difficult if you want to revert some changes to a
single patch but not do a full stack undo which would affect other
patches.

-- 
Catalin