Re: Using StGIT for tweaking already-committed stuff

On Sat, May 12, 2007 at 12:43:25AM +0200, Karl Hasselström wrote:

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 is great that this is possible, but I'm not sure I'll ever see it
as "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.

Hm.  I'm not that convinced :)

Eg, imagine a merge commit somewhere in the stack.  What would stgit
do with that ?

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.

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.

Best regards,
-- 
Yann.