Re: new stacked git feature

From: Karl Hasselström <kha@treskal.com>
Date: Feb 13, 2008, 00:08 UTC
Message-ID: <20080213000806.GB25839@diana.vm.bytemark.co.uk>
In-Reply-To: <1202834567.14175.68.camel@pc1117.cambridge.arm.com>

On 2008-02-12 16:42:46 +0000, Catalin Marinas wrote:

Show 9 quoted lines

> The background of this discussion is to have two or more StGIT
> repositories and keep them in sync. An idea is to share the exported
> patches directory and automatically synchronise them between various
> repositories (we already have a 'stg sync' command which I use for
> this kind of things but it's not automated).
>
> Yet another idea is to add some metadata to each commit log,
> something like a unique id so that one can recreate the stack with
> only a GIT revision id, without knowing the base.

I've been trying to come up with a good way to represent undo information, and my current plan is this:

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

  * The tree of a log commit contains:

      - A "patches" subtree, with one subtree per patch, named after
        the patch.

          + Each patch tree contains an "a" and a "b" tree, and a blob
            with the commit details including the sha1 of the commit
            object we use to represent the patch.

      - "applied" and "unapplied" blobs.

      - A version stamp blob, to make it easier to extend the log
        format in the future if we ever need to.

  * The log commit has one or more parents: zero or more log commits,
    and the current branch head commit.

This has a couple of features:

  * The log contains all the information necessary for resetting back
    to any given prior state. We might lose the commit objects of
    unapplied patches since they aren't reachable from the branch
    head, but we can recreate equivalent commit objects.

      - This means that one could pull a log branch from another
        repository and continue working on it.

      - It also means that all the other StGit metadata becomes
        redundant.

  * The log is able to represent any state, even "broken" states. This
    means that it's possible to undo "stg repair".

  * The log can represent nonlinear history -- that is, forks and
    merges in the state of the patch stack -- but, like git, says
    nothing about how the result of a merge is to be computed.

I've started to build this, but haven't gotten very far yet.

I wasn't planning to try to build patch stack merging until later, but here's how I imagine it would work:

  1. All patches are popped, and set to a special "conflicting" state
     with three or more "a" trees: a.ours, a.theirs, a.base0, a.base1,
     a.base2, .... Similarly for the "b" tree and the commit details.
     (Of course, trivial conflicts could be sorted out automatically
     at this point.)

  2. The merged stack base is created with a normal recursive merge.

  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.

I haven't even gotten far enough to test if this kind of merging gives sane results, but I think it might.

Feedback welcome on all of this, obviously.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle