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. - 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
