1. 21
  1.  

  2. 11

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

    1. Move among A, B, and C freely, adding commits (using git add -p if needed) with subject lines like B - add new class or even just A.
    2. When finished with your work, git rebase -i to put commits from A, B, and C together, using fixup. You may end with only 3 commits, or you may have a few more if you want to keep some commits from the same theme separate for whatever reason.
    3. During the interactive rebase use reword on the final commits as needed to write the final draft commit messages, which will now reflect the melded “fixup” history of the combined commits.

    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.

    1. 2

      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:

      1. Since you weren’t working with real commits the tool support was lacking
      2. Since you hadn’t actually committed anything you couldn’t push stuff to a WIP branch just so you could have a backup somewhere

      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.

      1. 1

        I was going to say something like this. You can also use —fixup to appropriate commits to one topic.

      2. 3

        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

        1. 2

          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.

          1. 1

            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.