Re: new stacked git feature

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

On 13/02/2008, Karl Hasselström [off-list ref] wrote:

quoted

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

quoted

  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.

quoted

  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