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:
>
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
