Re: new stacked git feature

From: Karl Hasselström <kha@treskal.com>
Date: Feb 13, 2008, 23:52 UTC
Message-ID: <20080213235204.GA10335@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0802131429p76f0981cm6e54a6a07042f229@mail.gmail.com>

On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:

Show 9 quoted lines

> On 13/02/2008, Karl Hasselström <kha@treskal.com> 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.

Show 6 quoted lines

> >   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.

Show 17 quoted lines

> >   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@treskal.com
      www.treskal.com/kalle