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

Jujutsu Megamerges and jj Absorb

v5.chriskrycho.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#41

Post by corytheboyd »

swaits wrote: post #10
corytheboyd wrote: post #5

Earlier quoted context omitted.

Huh this comment thread may have convinced me to finally try it. I’m comfortable with git, and fixing mistakes in git, but not being able to trivially reverse any and every transaction is annoying.

I made a mess of a jj repo recently. A big mess. Ran `jj op log`, found the operation I wanted, and just `jj restore`d my way back to that exact prior state. Then started what I was planning afresh and got it right. Felt magical. And I didn't have to learn anything like the hell of git refs. The UI is self-explanatory as long as you know the feature exists. Another very nice thing is that conflicts aren't roadblocks.…

Ah yes, I’ve heard it makes the hell of huge conflict ridden rebases a bit less annoying. Always wished I could just get to the end of the rebase to see it all in context, _then_ resolve conflicts, but with the option to resolve the obvious ones along the way too.

Re: Jujutsu Megamerges and jj Absorb

#42

Post by stouset »

stavros wrote: post #32
steveklabnik wrote: post #31

Earlier quoted context omitted.

Those are usually in your gitignore, right? Also, this behavior (automatically tracking) is configurable. I thought I would hate it but I actually really like it.

Yeah they usually are, I'm sure it's great because I add files more often than I ignore, but I need to be careful with the temporary files I write left and right in the repo dir during development.

Why? You can easily remove them if they’re accidentally added.

Re: Jujutsu Megamerges and jj Absorb

#43

Post by chriskrycho »

bjackman wrote: post #12

I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work: 1. Work on smaller projects with simple histories. Git is perfectly satisfactory. 2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel). jj is only interesting for part 2, but then it's only useful if it's easy to…

I actually find jj great for (1). The project I reference working on in this post is in exactly that bucket, and the kinds of things I do with it are not “complicated” but jj is still much, much better than working with Git—not least for the kind of workflow I showed in this post!

Re: Jujutsu Megamerges and jj Absorb

#44

Post by stavros »

stouset wrote: post #42
stavros wrote: post #32

Earlier quoted context omitted.

Yeah they usually are, I'm sure it's great because I add files more often than I ignore, but I need to be careful with the temporary files I write left and right in the repo dir during development.

Why? You can easily remove them if they’re accidentally added.

Just because I might not remember/notice, and I don't want sensitive data to be committed by accident if I put an env var on disk for some reason.

Re: Jujutsu Megamerges and jj Absorb

#45

Post by stouset »

stavros wrote: post #44
stouset wrote: post #42

Earlier quoted context omitted.

Why? You can easily remove them if they’re accidentally added.

Just because I might not remember/notice, and I don't want sensitive data to be committed by accident if I put an env var on disk for some reason.

If you check `jj status` regularly and/or use `jj split` to build up your commits (like `git add -p`) then you’ll notice. They might end up in your local repo (until a gc) at worst.

Re: Jujutsu Megamerges and jj Absorb

#46

Post by stouset »

williamdclt wrote: post #22
Valodim wrote: post #18

So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction. But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential. But so far I haven't found a way to real…

> this isn't something they'd ever need anyways. Oh I do that quite often, either because I didn’t realise I was committing on the wrong branch, or I decided to split my work in two branches, or i need some other unmerited change for my current branch… It’s usually a rebase —onto or cherry-pick, I’d say I agree it’s not simple. jj seems interesting, I’m very comfortable with git but I think its UX is terrible, but ev…

Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.

Re: Jujutsu Megamerges and jj Absorb

#47

Post by stavros »

stouset wrote: post #45
stavros wrote: post #44

Earlier quoted context omitted.

Just because I might not remember/notice, and I don't want sensitive data to be committed by accident if I put an env var on disk for some reason.

If you check `jj status` regularly and/or use `jj split` to build up your commits (like `git add -p`) then you’ll notice. They might end up in your local repo (until a gc) at worst.

Ah, that's not too bad then, thank you!

Re: Jujutsu Megamerges and jj Absorb

#48

Post by stouset »

bayindirh wrote: post #20
Valodim wrote: post #18

So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction. But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential. But so far I haven't found a way to real…

The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit. Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs. I personally never use rebase, and am a merge guy. I don't…

> I personally never use rebase

Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do.

Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj.

There are a ton of straightforward and useful workflows in git that are just completely impractical.

Re: Jujutsu Megamerges and jj Absorb

#49

Post by stouset »

bayindirh wrote: post #25
Certhas wrote: post #24

Earlier quoted context omitted.

I agree that the change isn't of comparable magnitude. But JJ changes the user facing conceptual structure of version control. It unifies working directory, stash, index and commit, and replaces them with a single thing. And it shows that all existing git workflows can efficiently be constructed on this much simpler conceptual basis. In my mind this demonstrates convincingly that gits conceptual model carries unneces…

From what I understand, all these different places/things (working directory, stash, index and commit) confuses, and comes across unnecessary to some people. They want a simpler solution, and less mental load during version control phase of their software, that's understandable. In my experience software developers come in two flavors. a) Developers who want to understand all the pieces they work with and have the de…

I was a git power user. I am comfortable with and understand the index, stash, rebases, the reflog, and all the rest. I have written a git implementation.

I have converted to jj and will never go back. It is simpler and more powerful.

Re: Jujutsu Megamerges and jj Absorb

#50

Post by stouset »

corytheboyd wrote: post #41
swaits wrote: post #10

Earlier quoted context omitted.

I made a mess of a jj repo recently. A big mess. Ran `jj op log`, found the operation I wanted, and just `jj restore`d my way back to that exact prior state. Then started what I was planning afresh and got it right. Felt magical. And I didn't have to learn anything like the hell of git refs. The UI is self-explanatory as long as you know the feature exists. Another very nice thing is that conflicts aren't roadblocks.…

Ah yes, I’ve heard it makes the hell of huge conflict ridden rebases a bit less annoying. Always wished I could just get to the end of the rebase to see it all in context, _then_ resolve conflicts, but with the option to resolve the obvious ones along the way too.

Yep, this was the thing that encouraged me to look at jj. I am so done with rebases where I’m stuck in some meta-state where I need to figure out exactly what needs to be done—linearly, right now, and without making any mistakes—but all the regular tooling to jump around and explore is unavailable until I’m finished with the whole thing.

I would honestly use jj for just this even if that was all it offered.

Post reply on HN