Item — HN Reader

The sibling comment mentions rerere. But you can solve this even without that.

I assume you mean develop has a few extra commits from remote meaning feature branch diverges a few commits earlier.

Let's say the commit where feature branch diverges from has hash `abc`.

So what I would do is

  git checkout abc
  # write the test, then suppose hash with test files is xyz
  git checkout feature
  git rebase --onto xyz abc

You will now have test commit as root of feature branch. And now you can move it wherever you want just like in my original answer.

1 comments

Yes, I am familiar with git rebase. I can virtually assure you that everyone here evangelizing jj is aware of it too. Most of us were git power users. Steve Klabnik certainly was. I was too.

Actually using git rebase is a pain in the ass when things don't go according to plan. Long chains of rebase conflicts suck. Making a mistake during a rebase sucks. Stashing sucks when you forget what branch the changes were on. Stashing also sucks when you have stash apply conflicts.

None of this is ever a problem in jj due to the fundamental design.

And you get some additional superpowers too. Today I was working on a feature that needs to be merged and deployed one piece at a time. There are (right now) four separate pieces, each comprising multiple commits. In jj it's just one linear chain of commits on top of `main` with four branch names assigned to the relevant interim commits. Each of those branches has an associated PR. When I need to make a change to something in one of the commits early in the chain, I just do it. If I need to make a new commit somewhere else in the middle, I just do it. It takes zero effort, and all later commits are automatically kept up to date with changes earlier in the tree. When I push, all the PRs are updated. When I end up merging the first of those four stages, there is zero work necessary to fix up the later three branches.

Try doing that with git.