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.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.

    This is the use-case I hadn’t considered. And it makes sense now that I think of it. Though I personally haven’t come across it, since I don’t typically work on multiple, cascaded features at a time. Most of my work as been with waterfall models, so I can understand that other approaches may indeed have cascading features in parallel.

    Thanks!