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.

  • HaraldvonBlauzahn@feddit.orgOP
    3·
    3 days ago

    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.

    Yep. There are also situations where rewriting history on branches under review is ok and desired - systems like gerrit work that way. But not github (you can push to an own work-in-progress branch on github, or even push to a branch with a merge request, but the github ui is not designed to review that).

    Especially large organizations favour history that is easier to read and mostly linear. This is not needed for a mom and pop web project of a company with three developers.

    In respect to the number of commits per feature - one commit per feature can be good. But often changes can be compartmentalized in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.

    • litchralee@sh.itjust.worksEnglish
      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!