Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. jj, an alternative to git, gets discussed a lot these days (1, 2, 3, 4) and is often pitched as a solution. While I’m very sold on the problems jj is trying to solve, the way it solves them hasn’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.1 That’s where git history comes in. It’s an experimental command that arrived across two releases, 2.54 (April, reword and split subcommands) and 2.55 (June, fixup subcommand). It got a flurry of attention on each release day, and then, as far as I can tell, not much community discussion since. Which is a shame, because IMO it already delivers several of the benefits people tout for jj without needing to switch your whole workflow. And the cool thing is that it’s part of the core git distribution, so you can try it without installing anything.

Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

jj, an alternative to git, gets discussed a lot these days (1, 2, 3, 4) and is often pitched as a solution. While I’m very sold on the problems jj is trying to solve, the way it solves them hasn’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.

That’s where git history comes in.

  • litchralee@sh.itjust.worksEnglish
    1·
    5 days ago

    TIL git history.

    That said, I’m trying to figure out what the target workflow is, specifically for the “autorebases all your branches to match” functionality. Assuming we are not talking about rewriting published history – and nobody should ever really be doing that anyway, when multiple commiters are using the same branch – I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other. The trouble I’m having is the number of commits per feature.

    If the number of commits per feature is 1, then that means each branch just has one commit that its dependent branch doesn’t have. What is the point of the branch then? Just have a single WIP branch and keep building a linear commit history. If you need to give someone one of the features, then give them the commit which inplemtns that feature and nothing afterwards.

    If the number of commits per feature is >1, then this is certainly more difficult to work with, and the appeal of git history starts to shine when dealing with WIP commirs. But why is the dev in this situation, where they’re building multiple dependent features but they’re none are fully complete yet? Because if they were complete, then I presume the dev should squash the commits so the number of commits per completes feature is 1.

    My current thought is that having >1 commits to implement a single feature is a transient condition, and good practice is to get to 1 commit per feature. Is there something I’m missing?

    • JackbyDev@programming.devEnglish
      1·
      3 days ago

      I don’t know, the number of times I’ve needed to make two small changes in parallel is certainly non zero. The amount of times I’ve been mostly done with a feature and began a new one before a PR was totally merged is certainly non zero. Even then, some changes can make more sense if broken it into multiple commits (a moot point at most teams since squash and rebase seems to be the norm). You can keep a linear history and still have multiple commits in a branch, just commit (har har) to reading instead of merging.

      Regardless, doing commit fixups and rewords are not necessarily rare. These commands are still super useful. Bear in mind that just because something isn’t useful to your workflow, git is used by many different people with many different types of workflows.