Git and Jujutsu: In Miniature

> git really forces me to make a lot of decisions I don’t actually care about. How will I save my WIP while I’m off on this quest? Do I want to juggle stashes and my working tree, or throw commits around? How will I get a commit where I want it? Do I need to come up with a branch name? And how much of all this needs to just sit in my head or pasteboard, lest I forget what I was in the middle of?

I am hearing this argument a lot, but I don't really get it. My grocery store forces me to make a lot of decision when it offers me 7 kinds of ketchup and 20+ kinds of cereal, but no one says "I am avoiding large grocery stores because they force me to make too many decisions". If you are feeling adventurous, try something new. If you just want to get some food and go, grab your favorite brands. And yes, a smaller store won't force you to choose, but there is good chance you won't like the food you buy there.

(For the problem described, I'd do as following: Save WIP work as temporary commit. No, you don't want to juggle stashes. You can do interactive rebase with "edit" mode and then cherry-pick extra commit - this'll let you make sure test passes after rebase too. Yes, you need to come up with branch name, any will go, like c_s_test. You will need to keep the name of previous branch in your head, but given author uses "develop" it should not be too bad. But this is all my preferences, if someone wants to do something else - more power to them.)

When people find out I use jj (Jujutsu), I often get asked some version of "how's it better than Git?" And while I can list a number of reasons why I think it's better and you could argue whether or not that reason is contrived or not, I think it's all missing the point.

I think it's better -- in the most pessimistic case -- to look at jj as reframing how you think about branches and commits in the same way that learning a type of Lisp reframes your thinking even if you're a full time Python developer and have zero intention of ever using a Lisp.

The idea of shuffling commits around without fear, changing your working train of thought mid-branch, etc. is natural... mindless, even. It's one command away and you get so much muscle memory executing that command you just do it automatically. (There's no fear because `jj undo` undoes any operation you did if you regret it. Of course there a ways to undo N operations back and so on too).

I use jj full time now, but even when I periodically go back to using git (for older projects I don't have a jj clone out for), it has altered the way I look at my stream of work. I think there's value in that.

That's the pessimistic case. The optimistic case is you should be using jj because it's better and there's almost zero downside to doing it (your coworkers don't even need to know).

(This blog post was great, I just expect and already see some people focusing on the minutia of how to Git golf your way to achieving the same thing easily when that doesn't invalidate that jj is good, in my opinion).

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.

The git example break away from how I use git immediately. I've been burned enough times by stash to not ever use it anymore - just create a new branch immediately.

This is all enormously complicated for no reason. If you find the missing tests, just send a PR to add the tests immediately. Why go through all the weirdness of stitching into this development branch? Just add the tests and then rebase your WIP branch on it.

Always blows my mind how much time we waste talking about Git instead of just using it properly. Cheatsheet:

- It's distributed horticulture. Your tools come saran-wrapped to the tree.

- Rebase flow. Keep your branches linear.

- Merge commits are BS

- There is no source control problem that rebase, rebase --onto, reset, and reflog can't fix

- Topology is everything. Add this to your aliases: https://stackoverflow.com/questions/1838873/visualizing-bran...

TL;DR: Keep your branches up to date. Feature flags are a huge red flag. Constant conflicts and the inability to have long lived branches is indicative of poor architecture and project layout.

Use "rerere" as a bandaid.

Why won't anyone think about the release managers.

To make it overcomplicated for git just to fake a point doesn't do it for me.

I am yet to see a real value to use JJ. Those kind of built-up posts I am seeing about JJ on HN tend to push me in the opposite direction.

1) do your test in your current branch, it's related to what you are doing. 2) commit, co master, co -b newtestbranch, PR it, merge in your branch after. You're going to squash rebase at the end anyway...