4 ms·

Can someone who has used this comment on whether learning the newish terminology and workflow pays off, vs doing what I do now in situations which this seems ta

by stinos 5y ago

Can someone who has used this comment on whether learning the newish terminology and workflow pays off, vs doing what I do now in situations which this seems tailored for: multiple branches, cherry-picking here and there and/or interactive rebasing when features have been tested and are ok to put into master, likewise when one feature needs changes from another branch?

jpgrayson 5y ago
I originally used mercurial and its queues (mq) extension and then found StGit when switching to an organization using git for version control. Thus I got used to the patch-stack model prior to really being exposed to git's interactive rebase. Some days I wonder if an interactive rebase oriented workflow would be good enough for me, but manipulating the patch-stack with StGit has become so second-nature that even the small amount of extra friction of `git rebase -i` sends me right back to StGit.
- acidbaseextract 5y ago
  Funny to hear that you learned patch queues with mq. mq was my favorite part of mercurial and it's how I learned to use patch queues too. Thank you for maintaining StGit — I really enjoy it as a tool! topgit is fine, but quite heavy. I don't use stg much at work with squash merge workflows, but I love it for personal projects or when I need to work on a series of commits with intricate change sequencing.
pm215 5y ago
I use it all day every day, and I really like it for the workflows I have, which are basically contributing to open source projects that use the "send patches by email for review, features should be sent as patch series with each commit doing one thing for ease of code review" workflow. If the thing you want to send off for code review is not "a commit" but "a series of maybe 10 to 30 carefully crafted commits", stgit just makes it very easy to create that series of commits and work with it, putting code changes into the right patches, reshuffling the patch order, etc, as you go along. It's possible to do all that with interactive rebase, but I never got the hang of that and find the stgit interface much more intuitive. In particular, the 'git rebase' manual suggests that the typical rebase workflow is "create a lot of commits, and some fixup commits, and then occasionally tidy up with interactive rebase". The stgit workflow is much more "keep your patchseries tidy as you go along" because it's trivially easy to say "actually this little change should go in the patch 15 commits before the one I'm currently at", or "actually let me unstack these last 5 commits and spend the next day creating patches that logically belong before them, and then tomorrow push those last 5 commits back on again". I use separate branches for different topics/features, but basically every branch is an stgit patchseries.

by stinos 5y ago

jpgrayson 5y ago

I originally used mercurial and its queues (mq) extension and then found StGit when switching to an organization using git for version control. Thus I got used to the patch-stack model prior to really being exposed to git's interactive rebase. Some days I wonder if an interactive rebase oriented workflow would be good enough for me, but manipulating the patch-stack with StGit has become so second-nature that even the small amount of extra friction of `git rebase -i` sends me right back to StGit.

acidbaseextract 5y ago
Funny to hear that you learned patch queues with mq. mq was my favorite part of mercurial and it's how I learned to use patch queues too. Thank you for maintaining StGit — I really enjoy it as a tool! topgit is fine, but quite heavy. I don't use stg much at work with squash merge workflows, but I love it for personal projects or when I need to work on a series of commits with intricate change sequencing.

pm215 5y ago

I use it all day every day, and I really like it for the workflows I have, which are basically contributing to open source projects that use the "send patches by email for review, features should be sent as patch series with each commit doing one thing for ease of code review" workflow. If the thing you want to send off for code review is not "a commit" but "a series of maybe 10 to 30 carefully crafted commits", stgit just makes it very easy to create that series of commits and work with it, putting code changes into the right patches, reshuffling the patch order, etc, as you go along. It's possible to do all that with interactive rebase, but I never got the hang of that and find the stgit interface much more intuitive. In particular, the 'git rebase' manual suggests that the typical rebase workflow is "create a lot of commits, and some fixup commits, and then occasionally tidy up with interactive rebase". The stgit workflow is much more "keep your patchseries tidy as you go along" because it's trivially easy to say "actually this little change should go in the patch 15 commits before the one I'm currently at", or "actually let me unstack these last 5 commits and spend the next day creating patches that logically belong before them, and then tomorrow push those last 5 commits back on again". I use separate branches for different topics/features, but basically every branch is an stgit patchseries.