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

191–200 of 210 posts

Re: Stacked Diffs with git rebase —onto

#191

Post by steveklabnik »

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

This part:

> You rebase feature-1 onto main:

feature2 moves as well. Basically, the behavior here is just the default.

Re: Stacked Diffs with git rebase —onto

#192

Post by tcoff91 »

1718627440 wrote: post #170
tcoff91 wrote: post #167

Earlier quoted context omitted.

Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command. When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I sp…

I guess I never had complex trees from such an action, just a bunch of parallel branches, but I would say splitting and picking commits from different branches is not exactly hard with git either. Also you can also see them in git, but they won't have change ids of course.

I know how to do everything in git that I can do in jj but the thing is I would never bother doing most of these workflows with git because it’s way more of a pain in the ass than with jj. I work with version control in a totally different way now because how easy jj makes it to edit the graph.

Within a day of switching I was fully up to speed with jj and I never see myself going back. I use colocated repos so I can still use git tools in my editor for blaming and viewing file history.

Sure even rebasing a complex tree in git can be done by creating an octopus merge of all leaf nodes and rebasing with preserve merges but like that’s such a pain.

Re: Stacked Diffs with git rebase —onto

#193

Post by eddd-ddde »

wakawaka28 wrote: post #154
martinvonz wrote: post #144

Earlier quoted context omitted.

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

Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though. I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. T…

> Rebasing is not that hard.

No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD.

There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

Re: Stacked Diffs with git rebase —onto

#194

Post by wakawaka28 »

eddd-ddde wrote: post #193
wakawaka28 wrote: post #154

Earlier quoted context omitted.

Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though. I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. T…

> Rebasing is not that hard. No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD. There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are:

- `git commit --fixup HEAD~3`

- `git rebase --autosquash HEAD~4`

The "less than 2 steps" part comes from fixing up more than one commit having no conflicts before the rebase. It is very common to want to stop or run test scripts at various points in the newly modified history, and rebase can trivially help you automate that (but only if you want).

Rebasing literally just does a sequence of steps in the order you specify. You can make those steps complicated, or not, without learning yet another tool. The complexity that is in the rebase tool is practically all necessary.

After using git for many years, I realize now that a lot of thought went into its design. The way it works, especially with the rebase tool, is superior to having a dozen single-purpose tools.

I don't think this particular thing is against the UNIX philosophy either. All of these operations are intimately related just like the operations that a FTP client might do. I can just imagine someone like you looking at FTP or rsync, and saying "This can be 20 different commands! Why don't they make my particular use case into its own command!" There is a place for that kind of logic, but all of the things jj supporters have proposed to me are way too niche to have their own separate commands. My commit edits are complicated, and `git rebase` makes them super simple.

Re: Stacked Diffs with git rebase —onto

#195

Post by wakawaka28 »

swaits wrote: post #182
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.

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

Lol you could just say you disagree. Is it SO alien to you that users of the most popular VCS in the world might like it the way it is? After arguing with you guys, the only deep fact coming through is that people like you get irrationally optimistic about new tools, after the old favorite doesn't appeal to you for some reason.

Re: Stacked Diffs with git rebase —onto

#196

Post by wakawaka28 »

steveklabnik wrote: post #176
wakawaka28 wrote: post #137

Earlier quoted context omitted.

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

For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes. But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of diffe…

Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's VCS to them honestly. If you are a programmer, I think git is the best.

Re: Stacked Diffs with git rebase —onto

#197

Post by wakawaka28 »

steveklabnik wrote: post #189
wakawaka28 wrote: post #181

Earlier quoted context omitted.

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

That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.

Re: Stacked Diffs with git rebase —onto

#198

Post by martinvonz »

wakawaka28 wrote: post #196
steveklabnik wrote: post #176

Earlier quoted context omitted.

For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes. But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of diffe…

Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's…

> There is probably some lingering unfamiliarity with git among jj enthusiasts as well.

I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.

Re: Stacked Diffs with git rebase —onto

#200

Post by martinvonz »

wakawaka28 wrote: post #194
eddd-ddde wrote: post #193

Earlier quoted context omitted.

> Rebasing is not that hard. No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD. There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are: - `git commit --fixup HEAD~3` - `git rebase --autosquash HEAD~4` The "less than 2 steps" part comes from fixing up more than one comm…

Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.
Post reply on HN