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

From: Karl Hasselström <kha@treskal.com>
Date: Oct 10, 2007, 07:45 UTC
Message-ID: <20071010074517.GC12970@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0710091401s280b3a12md9e700fb3ae007bf@mail.gmail.com>

On 2007-10-09 22:01:44 +0100, Catalin Marinas wrote:

Show 17 quoted lines

> On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:
> >
> > > 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
>
> Series.new_patch already creates a commit, why should we move the
> functionality to 'pick'?

I didn't say that. :-) You could accomplish the commit creation by calling Series.new_patch if you like.

> The only call to new_patch with commit=False seems to be from
> 'uncommit' (and it makes sense indeed).

Yes. For uncommit anything else would be insane.

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