Re: Using StGIT for tweaking already-committed stuff

From: Karl Hasselström <kha@treskal.com>
Date: May 12, 2007, 11:09 UTC
Message-ID: <20070512110955.GB22735@diana.vm.bytemark.co.uk>
In-Reply-To: <20070512071023.GD16903@nan92-1-81-57-214-146.fbx.proxad.net>

On 2007-05-12 09:10:23 +0200, Yann Dirson wrote:

Show 14 quoted lines

> On Sat, May 12, 2007 at 12:43:25AM +0200, Karl Hasselström wrote:
>
> > It shouldn't be necessary with a manual "assimilate" step. If
> > stgit finds that there are unadorned git commits on top of the
> > patch stack, it should do the assimilation automatically. With
> > that in place, "stg new" and "stg refresh" would be nearly
> > superfluous, since git-commit with and without --amend does the
> > same thing -- the only thing they won't do is give the user the
> > option of manually choosing the patch name.
>
> Hm. I'm not that convinced :)
>
> Eg, imagine a merge commit somewhere in the stack. What would stgit
> do with that ?

There are two cases:

  1. The merge commit is below the bottommost patch. This is perfectly
     OK, and nothing special has to be done. The only restriction is
     that we can't uncommit past the merge.

  2. The merge commit is above the topmost patch. (There may or may
     not also be other not-yet-stgitified commits above the topmost
     patch, below or above the merge commit.) In this case, stgit
     should not auto-assimilate the commits on top of the stack (since
     it can't be done for the merge commit), and a number of stgit
     commands (push, pop, new, ...) should refuse to work until the
     user has either reset the branch so that the merge disappears, or
     done "stg commit" on all the patches below the merge.

Note that these are the only cases: stgit should (and does) enforce the invariant that the applied patches form a consecutive series of commits, without "holes". This is why "stg new" would be forbidden in case (2).

The point is not that you should commit merges on top of your patches, of course. The point is that if you do, stgit should handle it gracefully. Right now you can commit all your patches and do a merge, but if you try to do it the other way around, stgit will break down on you -- but there's no real reason why it should.

> I quite like the idea of makeing it easier to mix them, and removing
> the real duplicates from stgit, but I think that we should be
> careful not to remove power from stgit while doing this.

I agree.

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