2008/6/17 Karl Hasselström <kha@xxxxxxxxxxx>:
> On 2008-06-17 11:24:53 +0100, Catalin Marinas wrote:
>> 2008/6/12 Karl Hasselström <kha@xxxxxxxxxxx>:
>> > 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
--
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
