On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:
> On 13/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>
> > * Every time the patch stack is modified (that is, any time an
> > StGit command modifies anything at all), a new commit is made
> > to a log branch. Each StGit branch has one such log branch.
>
> We already have another commit for the patch history. If we add
> this, we end up with 3 commit for each patch command. People already
> complained that StGIT is slow, I wouldn't go this route.
I intend to get rid of the current per-patch log. It doesn't save
enough information to be useful anyway.
As for the speed: we'll have to write one blob and one tree per
modified patch, plus one top-level tree and a small constant number of
blobs. (Caveat: my current implementation is too stupid to realize
that not all patches were modified all the time.) These simple
create-an-object-from-data-on-stdin commands should be fast enough
that this won't be a problem (and if a dozen extra calls to git is too
expensive, we'll just have to build a git command that can take them
all in one go).
> For undo, can we not keep the HEAD of the old stacks in a simple
> text file?
We could. (We'd have to keep the sha1s of all the patches there,
though, and not just HEAD. And the applied/unapplied files.)
> Or maybe use reflogs and only allow as many undos as information
> available in reflog.
Yes, complemented by some extra files (see above). That's certainly a
reasonable choice.
I'd like to try my scheme out first, however. It's potentially more
powerful, since it can be pulled between repositories and maybe even
merged.
> > 2. The merged stack base is created with a normal recursive
> > merge.
>
> A recursive merge with the HEAD of another stack containing similar
> patches? If yes, when pushing it is likely that the patches already
> in the base will be emptied during a three-way merge.
No, a merge of the stack _bases_, with all patches popped off. And
this would be a regular git merge, so no emptying of patches.
> > 3. When a conflicting patch is pushed, we do the following:
> >
> > 1. For each of .ours, .theirs, .base0, ..., create a new
> > "b" tree just like we do when we normally push a patch.
> > If there are conflicts, autoresolve them like
> > merge-recursive does internally.
> >
> > 2. Create the single new "b" tree by making a recursive
> > merge of all these updated "b" trees. Represent any
> > conflicts like we usually do when pushing patches.
>
> My idea is to merge each patch with the corresponding commit in the
> other branch and leave the base unchanged (like "stg sync"). The
> difficulty is in identifying which commit from the other branch has
> to be used. We could try guessing by the number of changes or just
> using the subject line, assuming that it won't change (or an extra
> id field in the commit text).
I was thinking about the same thing: just match up the patches with
the same name. If the user has renamed a patch, she can coalesce the
two manually.
> I find this workflow pretty difficult to implement since the StGIT
> patches are pretty volatile. It might be better to use topic
> branches instead.
I agree that it's far from certain that this will be a very useful
workflow. But I'm willing to bet a couple of day's work that it is, so
I'll build a prototype and see.
--
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
