I just skimmed the tutorial (so may be missing something) but it seems like many of the benefits can be reaped using a workflow I often use when working on sets of unrelated changes simultaneously:
Say you are making commits related to subjects A, B, and C (maybe A is “formatting cleanup”, B is “adding feature X”, etc).
git add -p
B - add new class
git rebase -i
This lets you work without worrying while you’re in flow, while retaining enough context to easily and quickly clean things up at the end.
Agreed. And being able to work like this was a major reason why I (and I suspect others) left Mercurial for Git.
I used to use a “patch stack plugin” for Mercurial as well, but two issues that kept cropping up was that:
There was a recent post on here that also took similar issues with Git’s workflow but I never understood why committing as you go and fixing up later wasn’t a viable solution. But maybe I’m just too set in my ways.
I was going to say something like this. You can also use —fixup to appropriate commits to one topic.
Glad they got a more modern website - the old one is here. Also see @ac’s blog post about it.
I tried this a while ago, no particular opinions on it, but I don’t think I’d be able to use it well - the conceptual overhead of Git is big enough for me, so debugging this/removing it from my workflow would be very hard. I might try it again since I’m looking for a parallel git-worktree-like workflow without having to think too much about branches, but I’d prefer learning a new tool to adding a layer
I tried to use it a few years ago. I don’t know if it still holds true but back then it felt pretty rough around the edges. To anyone finding the concept interesting but the implementation lacking: try Darcs.
It looks like you did end up checking it out. Were you able to find a Stacked Git flow that works for you?
As mentioned in the other thread, I’ve been using Stacked Git almost exclusively for the past several years. I’m happy to answer questions if anyone has any.