On 2008-06-17 15:11:42 +0100, Catalin Marinas wrote:
> 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.
Fair enough. I'll change it.
> > > > +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?
The log actually _contains_ those trees, so there is no problem.
(Relatedly: I've still not written the code that recreates a patch
from the trees and info if its old commit object is no longer present,
but it should be straightforward -- there's even a TODO at the right
place in the code.)
> > > > + - 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.
I think this question is settled by my answer above: the log actually
contains the trees in question, which it cannot do with the commit
object.
The applied and unapplied files do contain the sha1s of the patches'
commit objects, since most of the time they will still be there, and
we can just re-use them. But gc and pull don't "see" this kind of
pointer, so we can't rely on it.
> > > > +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 :-)
You want gitk master.stgit^, which is the simplified log. Can you
guess why I added it? :-)
The full log unfortunately has to look like hell, because it needs
both the stack top and the previous log entry as ancestors (since
ancestry is the only way to point to other commit objects that
survives gc and cloning).
> > That is, "stg log -g" in this patch series.
>
> This is more readable.
(This is just gitk <branch>.stgit^.)
> > 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.
Yes, much like diffs take some time to get used to if you haven't seen
them before.
If you have ideas for a better way to visualize this, I'm all ears.
> 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.
The reset command can already reset just a single patch and not all of
them.
I agree that a "revert"-style command, which undoes just one update
and not everything that happened since then (for the entire stack or
just a single patch), is an intriguing idea. I haven't thought about
it much, but I'm sure it's doable. (In fact, it should be equivalent
to patch stack merging, which I wrote a post about some time ago if
you recall.)
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
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
