Thread (35 messages) flat view 35 messages, 14 authors, 2016-06-15

Re: Using StGIT for tweaking already-committed stuff

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:43:09

On 2007-05-12 09:10:23 +0200, Yann Dirson wrote:
On Sat, May 12, 2007 at 12:43:25AM +0200, Karl Hasselström wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help