Stacked Diffs with git rebase —onto • Hacker News Board

Re: Stacked Diffs with git rebase —onto

#181

Post by wakawaka28 » Sat, Dec 06, 2025, 10:05 PM UTC

1718627440 wrote: post #166

martinvonz wrote: post #145

Earlier quoted context omitted.

> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script. I think jj is generally more useful for people like me wh…

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately. If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you sta…

>For me branches also represent features, that should have clear boundaries

I try to do this too but I often end up in situations where I have multiple incomplete (in testing, not merged) features with outstanding patches. Instead of one branch per topic, I end up with one branch for a bunch of related stuff. I then rebase and pause at the feature boundaries to do more testing. Sometimes, if I find myself doing this a lot, I will use the `exec` feature of `git rebase` to automate my testing.

I think rewriting all related branches can cause problems. It would be really weird to do interactively for one thing. The other problem is that you may have unrelated topic branches broken by such a change. If you have a broken patch X that reveals problem Y on branch Z1, but you are working on fixing that on Z2, you may lose your ability to reproduce the Z1 issue if X is fixed on every branch. What if you get conflicts on all those branches? What does this do to the reflog? Yikes! It seems more dangerous than git itself.

These complaints are very niche of course, but the problem of rewriting many branches at once is also very niche. It can cause more problems than it solves.

Re: Stacked Diffs with git rebase —onto

#182

Post by swaits » Sat, Dec 06, 2025, 10:14 PM UTC

martinvonz wrote: post #141

wakawaka28 wrote: post #130

Earlier quoted context omitted.

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…

> I don't even want to learn another commit graph model, because git's model is very good. I agree. That's why jj uses practically the same model. That's how Git can quite easily be used as a backend. > I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Like what? Perhaps we can improve it.

This isn't going to be a very HN-like comment. But it's rooted in fact: That is complete nonsense.

Re: Stacked Diffs with git rebase —onto

#183

Post by swaits » Sat, Dec 06, 2025, 10:17 PM UTC

brooke2k wrote: post #136

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…

I don't think it's pride, more that I don't see the problem that it solves for me. I don't find that git gets in my way at all, and I don't find it confusing. It's a pretty transparent tool that I use every day and hardly notice. I don't mind other people using jj, but I simply don't feel a need to try it. There's nothing prideful about that, it's just pragmatism.

Pragmatic is using the best tool for the job. Certainly subjectively, and arguably objectively, jj is the better tool in many ways.

My advice is to try it. You should like it, if you're in the majority of folks to give it a sincere shot. If you don't like it, cool. But then my advice changes. jj is probably the future. Adapt or become one of those old-timers who froze their learning in time.

Re: Stacked Diffs with git rebase —onto

#184

Post by swaits » Sat, Dec 06, 2025, 10:18 PM UTC

yegle wrote: post #92

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…

jj does not support git submodules, this precludes even a casual use on my own personal repo.

This is one I'm okay with. Git submodules are absolutely awful.

I recognize that some folks are stuck with it, and yeah, in your case jj probably just doesn't make sense. Stay tuned though.

Re: Stacked Diffs with git rebase —onto

#185

Post by swaits » Sat, Dec 06, 2025, 10:19 PM UTC

feelamee wrote: post #147

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…

Can you explain how to do same workflow in jj? It would be nice to compare bads and goodies of git/jj

Google is definitely your friend here. Plenty of tutorials online.

Re: Stacked Diffs with git rebase —onto

#186

Post by swaits » Sat, Dec 06, 2025, 10:20 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.

Frankly, this is a rather poor, uninformed excuse. Most people who try it grok the concepts in days. And they feel right at home in weeks. That's when you start hearing, "I'll never go back."

Re: Stacked Diffs with git rebase —onto

#187

Post by swaits » Sat, Dec 06, 2025, 10:21 PM UTC

bilalq wrote: post #86

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…

I have one and a half decades of muscle memory burned in with inoremap jj `^ It's not something I can just shift away from.

Definitely let your keybinding keep you from trying out and using a fantastic tool.

Re: Stacked Diffs with git rebase —onto

#188

Post by swaits » Sat, Dec 06, 2025, 10:22 PM UTC

IshKebab wrote: post #79

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…

> why not just use jj 1. It's very new; I haven't had time to learn it properly yet. 2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet. 3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess. I'm definitely in favour of better-than-Git alternatives but I don't think it's r…

`jj` isn't new. It's definitely not *very* new.

Re: Stacked Diffs with git rebase —onto

#189

Post by steveklabnik » Sat, Dec 06, 2025, 10:35 PM UTC

wakawaka28 wrote: post #181

1718627440 wrote: post #166

Earlier quoted context omitted.

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately. If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you sta…

>For me branches also represent features, that should have clear boundaries I try to do this too but I often end up in situations where I have multiple incomplete (in testing, not merged) features with outstanding patches. Instead of one branch per topic, I end up with one branch for a bunch of related stuff. I then rebase and pause at the feature boundaries to do more testing. Sometimes, if I find myself doing this…

jj doesn't force you to resolve the conflicts immediately, so it'll just show that they're conflicted until you decide you want to go fix them.

Re: Stacked Diffs with git rebase —onto

#190

Post by steveklabnik » Sat, Dec 06, 2025, 10:36 PM UTC

swaits wrote: post #183

brooke2k wrote: post #136

Earlier quoted context omitted.

I don't think it's pride, more that I don't see the problem that it solves for me. I don't find that git gets in my way at all, and I don't find it confusing. It's a pretty transparent tool that I use every day and hardly notice. I don't mind other people using jj, but I simply don't feel a need to try it. There's nothing prideful about that, it's just pragmatism.

Pragmatic is using the best tool for the job. Certainly subjectively, and arguably objectively, jj is the better tool in many ways. My advice is to try it. You should like it, if you're in the majority of folks to give it a sincere shot. If you don't like it, cool. But then my advice changes. jj is probably the future. Adapt or become one of those old-timers who froze their learning in time.

This is really over the top and unnecessary.