Git Is Not Fine

Very often when writing a new feature, I have to fix a bug in another subsystem (and write tests for it), add a small capability to another subsystem, fix documentation elsewhere, and so on.

Those could be separate commits in one PR, and that’s the way I’ve historically worked. But in jj it’s trivial to make them separate branches and continue working on the merge of all of them, even if they haven’t been merged upstream yet.

The benefit is that my coworkers have absolutely trivial PRs to review, rather than one omnibus. If there’s some debate about one of them, not only can we still make progress by merging the others, but I can continue plugging away on my main feature branch while we decide on the best path forward. If one of those PRs needed a bugfix or changes, fixing them typically m requires quite literally zero VCS shuffling to incorporate into the work downstream.

My pace of and ability to work on features is no longer bottlenecked by reviews. My coworkers no longer have to review giant PRs that touch seven subsystems. I don’t have to wait until an entire feature is finished before coworkers can start merging smaller preparatory bits for it.

You can do some of this stuff in git. But it’s excruciating and so nobody does it except in rare circumstances.

I totally agree. I've never understood the push back against clean "railroad tracks" (i.e. rebasing instead of merge commits). It's simple, scales nicely and gives you a lot of options. Once you start allowing merge commits in the tree, things can get messy but with a bit of discipline, it elegantly solves every version control use-case I can think of, or have encountered, including at scale.

I work primarily in c++ and fully agree with the author. I think it makes more sense in the context of larger teams, possibly also monorepos. Review speed (both latency of feedback and how thorough your reviewers are), presubmit test runtime, flake rate, etc can lead to it taking a few days to get work submitted. In some cases you don't want to land work until you've finished a milestone of some sort. If others work on similar files to you, you will end up with several rounds of rebase conflicts to deal with too.

Stacked PRs is mostly a way to avoid thousand- or tens-of-thousands- LOC branches, which makes each PR meaningfully reviewable. You need a good code review process for it to become useful. It’s very pleasant once you are accustomed to it.

I’ve seen successful teams that regularly do reviews of massive PRs and feel this serves them well enough. I suspect it just places a lot more trust on the developers to get the details right so reviewers only look at larger design issues.

The language of choice is not relevant. Even before AI, one can accumulate thousands of lines of c++ easily.

Nothing to understand. It's the JJ spam post of the week.

A piece of software looking for a problem to solve.

Do you remember the TV ads where people were acting like imbeciles to sell you their junk products for 3 easy payments of 19.99?

There is an open source & git compatible version of Meta's VCS: https://sapling-scm.com/

I use AI prolifically for coding, but I haven't crossed the chasm of letting it do mutable operations on my vcs. It tends to revert changes too eagerly. Commit messages written by it usually miss the point of the commit and end up too verbose and need to be modified or completely rewritten in many cases. I feel like prose needs to capture style which is unique per individual which makes it difficult to do well.

IIUC, jj was heavily inspired by hg. In particular, the revsets and the UI.

You should look into `update-refs` functionality. By default git treats each branch independently, but with update-refs, git tracks pointers to branches and creates a dependency chain.

I don't mean to suggest you're doing something wrong, but it's not clear to me why you need three separate branches for this? Why not have these related changes as individual commits on a single branch?

> Then simply `git branch -f a-branch <logical same point on rebased>` for each of the others, done.

Yep, and after 2022 you can do this with --update-refs.

Situation 1: main has moved ahead, pull it and move whole stack (say feat1..N) on top of that

  git switch main
  git tag old main
  git pull --rebase
  git rebase --onto main old featN --update-refs
  nvim app/config.py # fix conflicts if necessary
  git add $_
  git rebase --continue
  git push origin feat{1..N}

  git switch feat1
  nvim app/models.py
  git add app/models.py
  git commit -m 'make username unique'
  git rebase feat{1,N} --update-refs
  git push origin feat{1..N}

Are we talking about the same git where—notoriously—one of the best ways to become proficient was to read Git From the Inside Out[1] replete with over 20 diagrams showing how various commands perform tree manipulations?

[1] https://news.ycombinator.com/item?id=12802949