git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Using StGIT for tweaking already-committed stuff

From
Yann Dirson <ydirson@altern.org>
Date
May 12, 2007, 07:10 UTC
Message-ID
<20070512071023.GD16903@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To
<20070511224325.GA13310@diana.vm.bytemark.co.uk>
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" :)

Show 7 quoted lines
> 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 ?

Show 11 quoted lines
> 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.
Previous: Karl HasselströmNext: Karl Hasselström
Message 18 of 35 in “Merging commits together into a super-commit”
  1. Alex BenneeMay 10, 2007
  2. Raimund BauerMay 10, 2007
  3. Alex BenneeMay 10, 2007
  4. Johannes SchindelinMay 10, 2007
  5. Johannes SixtMay 10, 2007
  6. Linus TorvaldsMay 10, 2007
  7. Carl WorthMay 10, 2007
  8. J. Bruce FieldsMay 10, 2007
  9. Carl WorthMay 10, 2007
  10. Petr BaudisMay 10, 2007
  11. Carl WorthMay 10, 2007
  12. Using StGIT for tweaking already-committed stuffPetr Baudis, May 10, 2007
  13. Carl WorthMay 10, 2007
  14. Integrate StGIT into Git? (Was: Re: Using StGIT for tweaking already-committed stuff)Jan Hudec, May 11, 2007
  15. Karl HasselströmMay 10, 2007
  16. Yann DirsonMay 11, 2007
  17. Karl HasselströmMay 11, 2007
  18. Yann DirsonMay 12, 2007
  19. Karl HasselströmMay 12, 2007
  20. Robin RosenbergMay 10, 2007
  21. Yann DirsonMay 12, 2007
  22. Jakub NarebskiMay 12, 2007
  23. Karl HasselströmMay 12, 2007
  24. Yann DirsonMay 12, 2007
  25. Karl HasselströmMay 12, 2007
  26. Junio C HamanoMay 12, 2007
  27. Karl HasselströmMay 13, 2007
  28. Yann DirsonMay 13, 2007
  29. Store branch description in the config fileKarl Hasselström, May 14, 2007
  30. J. Bruce FieldsMay 10, 2007
  31. Petr BaudisMay 10, 2007
  32. J. Bruce FieldsMay 10, 2007
  33. Transactions for git (and stgit) ?Yann Dirson, May 12, 2007
  34. Karl HasselströmMay 12, 2007
  35. Yann DirsonMay 12, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.