Re: Using StGIT for tweaking already-committed stuff

From: Karl Hasselström <kha@treskal.com>
Date: May 11, 2007, 22:43 UTC
Message-ID: <20070511224325.GA13310@diana.vm.bytemark.co.uk>
In-Reply-To: <20070511204016.GH19253@nan92-1-81-57-214-146.fbx.proxad.net>

On 2007-05-11 22:40:17 +0200, Yann Dirson wrote:

Show 7 quoted lines

> On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:
>
> > But you can kind of do it today. Just commit with git (my favorite
> > here is the emacs modes) and "stg assimilate"!
>
> Well, that's arguably a non-orthodox way of doing things, I like the
> idea your "stg new" patch much better :)

It's only unothodox if you expect git and stgit to not always mix so well. But if we have the ambition that they should interoperate as near to seamlessly as we can make them, this kind of workflow becomes very natural.

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.

I believe this sort of integration is the way to go. It'll be beneficial for git users who want to occasionally use some stgit to rebase their patch series, since they'll not have to learn more than two or three new commands in addition to the git they already know. Heavy stgit users will benefit from having the much larger git community maintaining a large subset of the porcelain they use, instead of having to duplicate the effort and always lag behind.

This is no binary choice, of course. One could certainly imagine a compromise where stgit becomes much easier to mix with git than today, but still retains the current command set.

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