Item — HN Reader

Why won't this work to achieve the exact same thing?

  # on branch `feature`
  # code code code
  # whoops! Test missing
  git add wip/ changes/ && git commit -m lol
  git checkout develop
  # write the test
  git add test/ files/ && git commit -m lol2
  # back to WIP branch
  git checkout feature
  # open vim and put the lol2 commit in the right place
  git rebase -i develop
  ?lol2<cr>dd/3e7<cr>P:wq
  # undo the original lol commit
  git reset HEAD~1

You could use git stash instead of making and resetting the `lol` commit but i just prefer to do it this way.

1 comments

You can, but this sort of glosses over all the ways this can quickly get confusing.

I’ve had this exact scenario happen where develop had multiple commits and the rebase caused a chain of having to resolve rebase conflicts in each commit. Then I fuck up one of those and I have to completely start over. And during this process I’m “stuck” in the rebase state and can’t use regular tools to manage and track my work.

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.

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.

rerere in git config helps, but if jj just does it all more sanely, it's probably worth learning for people who don't yet have the git-fu.

Rerere sort of helps, sometimes, but like so many things with git (the stash, wip commits, fixup commits, squash rebasing) it’s yet more hacky fixes over the design being not quite right.