Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch

From: Karl Hasselström <kha@treskal.com>
Date: Oct 8, 2007, 13:25 UTC
Message-ID: <20071008132524.GA11253@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0710080616r36142946m3e24d2f6893287c9@mail.gmail.com>

On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:

Show 15 quoted lines

> On 14/09/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>
> > +        assert commit or (top and bottom)
> > +        assert not before_existing or (top and bottom)
> > +        assert not (commit and before_existing)
> > +        assert (top and bottom) or (not top and not bottom)
> > +        assert not top or (bottom == git.get_commit(top).get_parent())
>
> The last assertion here prevents the use of 'stg pick --reverse'.
> This command creates an unapplied patch with top and bottom reversed
> and pushes it to force a three-way merge.
>
> It seems to work OK if I comment it out but I wonder whether it will
> break in the future with the planned removal of the top and bottom
> files.

I think the assert represents a real constraint, namely that there has to be a 1:1 correspondance between patches and commits.

Couldn't "stg pick --reverse" create a new commit and use that? That is, given that we want to revert commit C, create a new commit C* with

  tree(C*)   := tree(parent(C))
  parent(C*) := C

Creating just one new commit object seems like a cheap thing to do.

And shouldn't there be a test for this? :-)

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