Stacked Diffs with git rebase —onto • Hacker News Board

Re: Stacked Diffs with git rebase —onto

#121

Post by stouset » Fri, Dec 05, 2025, 10:36 PM UTC

hansvm wrote: post #70

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 zer…

If jj took many weeks of relearning, I might be right there with you. But the overwhelming majority of people I’ve personally seen who try the switch convert within a day, are barely slowed down by day two, and are effectively fluent within three days to a week at most.

Re: Stacked Diffs with git rebase —onto

#122

Post by steveklabnik » Fri, Dec 05, 2025, 10:37 PM UTC

mhitza wrote: post #80

pimeys wrote: post #25

Earlier quoted context omitted.

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).

This looks like any other git arcane incantation. If this is a common pattern and jj aims to make things easier, should probably be part of the core commands, no?

It's something that makes a specific workflow easier, a lot of folks that use jj don't necessarily use that workflow.

That doesn't mean it couldn't be a core command someday, but given that the alias works well for people, there's not a ton of reason to make a whole new command. You configure the alias and you're off to the races.

Re: Stacked Diffs with git rebase —onto

#123

Post by stouset » Fri, Dec 05, 2025, 10:38 PM UTC

dlisboa wrote: post #75

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…

There is also mental friction with learning an entirely new tool. `jj` is different enough from `git` that one can't transfer knowledge. Currently the documentation is not good enough to assuage that issue.

This really isn’t true. All of my git knowledge—except for the CLI flags—is directly useful for jj.

The jj CLI is very easy to grok, even for a seasoned git user. Maybe even especially so for a seasoned git user.

Re: Stacked Diffs with git rebase —onto

#124

Post by steveklabnik » Fri, Dec 05, 2025, 10:39 PM UTC

ptx wrote: post #76

What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar". Mercurial's "histedit" command offers two operations to combine the commits: "fo…

If you ever try out jj, both fold and roll exist as `jj squash`. You'd choose as the destination the change of the time you'd want to keep.

Re: Stacked Diffs with git rebase —onto

#125

Post by steveklabnik » Fri, Dec 05, 2025, 10:52 PM UTC

unshavedyak wrote: post #74

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…

Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj: 1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work i…

"creating a commit would abandon the branch" is certainly something lost in translation. There are other reasons you may have not liked the UX, largely that if you create branches and then add a bunch of commits after it, the branch head doesn't automatically move by default. There is a config setting you can change if you prefer that, or the `jj tug` alias some people set up.

Auto-commit is still a thing, but you can regain the stuff you like with a workflow change, this is called the "squash workflow" and is very popular: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

Re: Stacked Diffs with git rebase —onto

#126

Post by sunshowers » Fri, Dec 05, 2025, 11:01 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…

Jujutsu is not a Git frontend, it is an independent VCS that is compatible with Git. This is important because it has concepts and ideas of its own. It is used entirely independent of Git within Google.

Re: Stacked Diffs with git rebase —onto

#127

Post by azophy_2 » Fri, Dec 05, 2025, 11:12 PM UTC

I feel that stacked PR in git should be common knowledge, however many of the documentations are scattered. I found stacked.dev but feels that its not exploring pure-git workflow that well. thats why I tried to collect all of those docs into a single website that's dedicated into that singular workflow. would love to get any feedback:

https://stacked-pr.github.io

(disclaimer: partly supported by AI, but most of the writing structure were made by hand)

Re: Stacked Diffs with git rebase —onto

#128

Post by conradludgate » Fri, Dec 05, 2025, 11:13 PM UTC

oscillonoscope wrote: post #91

unshavedyak wrote: post #74

Earlier quoted context omitted.

Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj: 1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work i…

I more or less use the method described [here]( https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... ) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `…

_Every time I see one of these nifty jj tricks or workarounds I find myself wondering, “why not just use git?”_

Re: Stacked Diffs with git rebase —onto

#129

Post by imron » Fri, Dec 05, 2025, 11:17 PM UTC

url00 wrote: post #57

imron wrote: post #20

Earlier quoted context omitted.

The capability is there. Just use git rebase --update-refs ...

Wow you aren't wrong, the first blog post on Google talking about this is exactly what this complicated method does just built-in.

To be fair --update-refs was only added in git 2.38 (released in 2022) so it’s likely that OPs workflow came about before this flag was introduced.

Re: Stacked Diffs with git rebase —onto

#130

Post by wakawaka28 » Fri, Dec 05, 2025, 11:50 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…

This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used.

Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature-rich than git. I don't even want to learn another commit graph model, because git's model is very good. About 95% of what people like yourself call "git nonsense" consists of useful features that many people would be annoyed to not have.

I believe that a large number of git or general VCS users have no idea about commit hygiene. They have not had to cherry-pick or edit commits, and have no idea what to do about conflicts. To people like that, git's features and methods will appear especially foreign.

I looked over jj specifically many moons ago and concluded it would annoy me and not function at my job. I forgot what the reasons were. One reason was most likely because I need submodules and worktrees to work. I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Nothing is more compatible with git than git itself, and I am very satisfied with how well git works for me.