Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stacked Diffs with git rebase —onto

dineshpandiyan.com

Post reply on HN
Print view View original

141–150 of 210 posts

Re: Stacked Diffs with git rebase —onto

#141

Post by martinvonz »

wakawaka28 wrote: post #130
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…

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

Re: Stacked Diffs with git rebase —onto

#142

Post by wakawaka28 »

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.

>Like what? Perhaps we can improve it.

I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do anything with it, then loudly complain about it being tricky. Anything as complicated as version control is going to be tricky if you don't read the manual. I don't think making another tool entirely is the right solution. Perhaps a different set of git porcelain tools could help, or some git aliases. Maybe better documentation too. But some people just can't be pleased.

Re: Stacked Diffs with git rebase —onto

#143

Post by wakawaka28 »

martinvonz wrote: post #139
wakawaka28 wrote: post #137

Earlier quoted context omitted.

What is the most useful feature of jj that you think git doesn't have?

I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.

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. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this feature, rebasing all the other branches (realistically, probably like 1 or 2) would be easy enough to do manually with the feature described in this post. Rebasing and touching up commits is very easy with git interactive rebase. There are also features to automatically reorder commits with, e. g., `git commit --fixup` and `git rebase --autosquash`.

If you have others in mind then go ahead lol. I was just trying to make it easy.

Re: Stacked Diffs with git rebase —onto

#144

Post by martinvonz »

wakawaka28 wrote: post #142
martinvonz wrote: post #141

Earlier quoted context omitted.

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

>Like what? Perhaps we can improve it. I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do…

This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.

> I don't think making another tool entirely is the right solution.

I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

Re: Stacked Diffs with git rebase —onto

#145

Post by martinvonz »

wakawaka28 wrote: post #143
martinvonz wrote: post #139

Earlier quoted context omitted.

I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.

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. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this…

> 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 who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).

Re: Stacked Diffs with git rebase —onto

#146

Post by RadiozRadioz »

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?”

The most common reason is that the git user has no idea it exists. I am in this bucket alongside 99% of git users.

There are an assortment of other potential reasons:

- It is a new tool that hasn't been battle tested as much as git has, which can decrease confidence.

- Git has inertia. People have learned it, it takes less effort to add a new git skill to your repertoire than learn a new tool from scratch, even if the new tool is easy to pick up.

- Due to its novelty, the auxiliary tooling ecosystem for jj is smaller (does it have plugins for all the popular editors? Lots of people like those, git's are high quality)

- Git is good enough. It's not perfect, but its popularity means that its shortcomings have readily available fixes or tweaks from users. It simply isn't bad enough and there are bountiful resources on how to use it effectively.

Re: Stacked Diffs with git rebase —onto

#147

Post by feelamee »

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

Re: Stacked Diffs with git rebase —onto

#148

Post by feelamee »

tcoff91 wrote: post #115
1718627440 wrote: post #110

Earlier quoted context omitted.

> Also, anonymous branches are SOOOO much better than git stashes. You can do anonymous branches in Git as well. I use both for different use cases.

The UX around anonymous branches in git is not nearly as good as jj though. Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.

isnt jj undo the equivalent of git reflog (+ reset/checkout)?

Re: Stacked Diffs with git rebase —onto

#149

Post by mytailorisrich »

azophy_2 wrote: post #127

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

If you adopt a good continuois integration process you don't need stacked commits at all, which are more a symptom of a process issue, IMHO.

It's fashionable at the moment so there is a bit of herd mentality going on. In 2 years they'll be a reinvention of the wheel again against it.

Re: Stacked Diffs with git rebase —onto

#150

Post by qff »

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` doesn’t allow temporary files in the repository that aren’t listed in `.gitignore`.

This makes it unusable for me.

Post reply on HN