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.

  • Vorpal@programming.devEnglish
    1·
    2 days ago

    For me this is a killer feature. For a start, we value atomic commits, where each commit does one small standalone thing. This makes review easier, as well as going back and looking at history to figure out why something was done the way it was. An easy to read history is critical at a large company. Commit messages are often muliline and long and describe the why and why not other alternatives that were considered.

    But this also means your PR branch should have clean history, and editing said history is absolutely encouraged (even mandatory). We use azure devops and flawed as it is, the review UI handles this case well. I believe github is far worse at handling force pushes.

    Review, design review and even CI runs takes time, so I often need to start building on top of a PR before it is fully finished and merged. Because I work in a sector where we have actual certifications (safety critical systems, think things like brake controllers, medical devices, etc) this means “move fast and break things” just isn’t an option (nor should it be). This also slows down the PR workflow. Even after the C++ code built, you can expect a few hours to run the test suite with full physical simulations. And review can take days for larger and more critical changes.

    So yes, many branches have more than one commit. And it is not uncommon to build upon yet to be merged branches (with the knowledge that small things will need to change as the followup is being rebased on top of changes of the original PR).