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, 14:11 UTC
- Message-ID
- <b0943d9e0806170711w6da8e841p3ac83a59a81f6577@mail.gmail.com>
- In-Reply-To
- <20080617123138.GA6932@diana.vm.bytemark.co.uk>
2008/6/17 Karl Hasselström <kha@treskal.com>:
Show 13 quoted lines
> 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.
Show 12 quoted lines
>> > --- /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.
Show 11 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?
>
> 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?
Show 21 quoted lines
>> > + - 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.
Show 7 quoted lines
>> > +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