Stacked Diffs with git rebase —onto • Hacker News Board

Re: Stacked Diffs with git rebase —onto

#61

Post by quietbritishjim » Fri, Dec 05, 2025, 2:30 PM UTC

Hendrikto wrote: post #47

swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

It’s a bit like qwertz. Sure, it is not optimal, there are better alternatives available. But it is good enough, and it is universal. That trumps a 5% typing improvement on my own custom keyboard layout at the cost of not being able to use my coworkers keyboard. Also, I dislike all of the alternate git frontends I tried, because they are opinionated in a way they clash with my workflow. Moreover, I don’t think the gi…

> Most problems people report stem from a refusal to learn the underlying structure and models.

It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do. Like, yes it's complex, but surely that's just intrinsic complexity of the problem? (Also, I think we all sometimes feel like someone with a different view must just not know as much as us.)

But if you have used other version control systems (I'm thinking particularly Mercurial here) you realise that actually some of that complexity is just totally made up by git.

Re: Stacked Diffs with git rebase —onto

#62

Post by nopurpose » Fri, Dec 05, 2025, 2:30 PM UTC

onionisafruit wrote: post #60

nopurpose wrote: post #9

That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.

Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years. I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.

discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.

Re: Stacked Diffs with git rebase —onto

#63

Post by mytailorisrich » Fri, Dec 05, 2025, 2:32 PM UTC

Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged?

Having to rebase again and again is a symptom that a dev branch is living for too long.

Re: Stacked Diffs with git rebase —onto

#64

Post by onionisafruit » Fri, Dec 05, 2025, 2:34 PM UTC

nopurpose wrote: post #62

onionisafruit wrote: post #60

Earlier quoted context omitted.

Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years. I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.

discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.

I plan to pay it forward today with a post on my work slack. I just need to try it a time or two myself first.

Re: Stacked Diffs with git rebase —onto

#65

Post by nopurpose » Fri, Dec 05, 2025, 2:35 PM UTC

duskdozer wrote: post #31

nopurpose wrote: post #9

That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.

I'm guilty lol. I wrote a helper to do rebase chains like this

update-refs works only in a narrow case when every branch starts form the tip of a previous. Your helper might still be useful if it properly "replants" whole tree keeping its structure.

Re: Stacked Diffs with git rebase —onto

#66

Post by ptx » Fri, Dec 05, 2025, 2:43 PM UTC

mhw wrote: post #56

ptx wrote: post #41

Earlier quoted context omitted.

How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs": $ git checkout feature-1 $ git rebase --update-refs main Successfully rebased and updated refs/heads/feature-1. Updated the following refs with --update-refs: refs/heads/feature-2-base But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I…

Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case $ git rebase --update-refs main feature-2

Thanks! Yup, that does the trick.

Re: Stacked Diffs with git rebase —onto

#67

Post by [deleted] » Fri, Dec 05, 2025, 2:48 PM UTC

pimeys wrote: post #25

arccy wrote: post #22

Earlier quoted context omitted.

note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits. this is less of a problem if you're more into the 1 change == 1 commit workflow.

There's a very common alias `jj tug` for this case: tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"] It moves the nearest bookmark to the commit before the current one (which should be your working commit).

[deleted]

Re: Stacked Diffs with git rebase —onto

#68

Post by michaelbuckbee » Fri, Dec 05, 2025, 2:48 PM UTC

smcameron wrote: post #44

swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

For me, the answer is stgit. https://stacked-git.github.io/

That's really neat.

Re: Stacked Diffs with git rebase —onto

#69

Post by andrebianchessi » Fri, Dec 05, 2025, 2:56 PM UTC

Stacked commits is awesome, but it sucks that with git you need all these workarounds, and that the servers (GitHub etc) are not designed with that workflow in mind.

I left Google a few months back to work on another project. I missed the internal version control so much that I dropped that other project and am now focused http://twigg.vc It's very similar to what's used at Meta and Google. Atomic commits, linear history, auto rebase, code review compatible with stacked commits.

Re: Stacked Diffs with git rebase —onto

#70

Post by hansvm » Fri, Dec 05, 2025, 2:59 PM UTC

swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

> introduces some mental friction in walking away???

I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zero. Switching to jj means learning another tool to achieve similar outcomes on your workflows.