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

21–30 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#21

Post by dijit »

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…

You’ll find this to be true about many things.

For example, the solution to almost all problems is oddly kubernetes shaped even though that was not the case 15 years ago. And Google themselves would be the 1st to tell you that kubernetes is not capable of doing all jobs.

Monocultures are insidiously bad, they poison solutions and reasoning, but they have their upshots too- if you never need to learn a new mental model; us tech workers become more interchangeable and the cost to onboard goes down.

Re: Jujutsu Megamerges and jj Absorb

#22

Post by williamdclt »

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 everyone use git and it is not an area where I have capacity or willingness to innovate. I’d love to see git being replaced with something better designed though

Re: Jujutsu Megamerges and jj Absorb

#23

Post by sausagefeet »

jj might be the future. I certainly hope git is not. My current system is Mercurial with hg-git and evolve, and so far I find this to be fantastic for local development. There are a few rough edges but I just find hg so simple to use and consistent in functionality. I can usually just figure out how to do what I want from the --help screens. In git I often read the man page for a commit and then I just ask ChatGPT how to do it because the man page for each sub command is a novel. I hope that jj will aim for simplicity in the long run but I guess we'll see.

Re: Jujutsu Megamerges and jj Absorb

#24

Post by Certhas »

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 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 unnecessary incidental complexity. Within a fixed complexity budget jj absolutely does allow new things to happen.

I also don't really see any workflow examples that truly suffer under jj, so I don't think it's just another trade-off. It's a real substantial improvement. If it wasn't it wouldn't be making headway against gits network effects.

Re: Jujutsu Megamerges and jj Absorb

#25

Post by bayindirh »

Certhas wrote: post #24
bayindirh wrote: post #20

Earlier quoted context omitted.

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 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 desire to deep-dive into them b) Developers who write and commit code. They think that former part is their job and care about it. They don't care after it leaves their machine (in the sense of "I give box to machine it magically integrates").

IMHO, jj is very enticing for the latter camp, and that's not a bad thing. Not all of us are passion programmers/developers, and some are don't want to think about beyond their immediate realm. I respect these people. But, again, from my perspective, jj doesn't make sense for me. It's useful alright, but I actively use index, commit and stash very naturally. I might be good at understanding it because Eclipse has a great git integration which makes everything super workable and understandable, and I'd never change a power tool like git to something "push button, magic happens" class of tool.

jj might be very conductive to more complex workflows by removing some complexities, but unifying my stash, staging area and index is not something I want to be dome to my workflow for example.

Some trade-offs make great headways into networks because a large part of that network is silently suffering without being aware, and the trade-offs are worth it. See Rust for example. People accept 5x mental load and 10x compile times for memory safety. Same for jj. People accept a much simpler interface because it makes their painful workflows "push button, magic happens" levels of simplicity. Or, the people who like jj work under time pressure and want to remove a time-sink from their workflows, again understandable and respectable.

Having something like "jj" is not a bad thing. What I'm squarely against is "git is dead, new king is jj. Now move to your new kingdom and worship jj" mentality.

Re: Jujutsu Megamerges and jj Absorb

#26

Post by evgpbfhnr »

How does jj handle very large git repos, e.g. this linux clone with a mix&mash of quite a few upstreams with a 6GB big .git dir?

(I agree I probably shouldn't focus on that first, and could just try jj first on smaller rpos... But git is already slow enough in there that it's an honest question, I don't need to keep using git there as long as I can keep pulling from stable kernels git trees for regular merges)

Re: Jujutsu Megamerges and jj Absorb

#27

Post by evgpbfhnr »

stouset wrote: post #13
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…

Just try it! I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is. Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugg…

> Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.

That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?

Re: Jujutsu Megamerges and jj Absorb

#28

Post by do_not_redeem »

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 think you have it backwards. jj is absolutely for "a) Developers who want to understand their tools". The simpler data model opens up new workflows that weren't possible before.

Unifying concepts is not taking away any expressive power. It just makes the system as a whole simpler to reason about.

I think it's a similar step up in power as moving from Windows to Linux. On Windows, to toy with the system at all you need to set up a C++ project and dig through win32 API docs and deal with opening/closing handles and void* pointers just to change anything, so I rarely bothered. On Linux everything is right there in the file system so there's almost no friction to changing things. You can do anything imaginable in a minute or two with just a shell script.

In Linux, Everything Is A File. In Jujutsu, Everything Is A Commit.

Re: Jujutsu Megamerges and jj Absorb

#29

Post by Macha »

evgpbfhnr wrote: post #26

How does jj handle very large git repos, e.g. this linux clone with a mix&mash of quite a few upstreams with a 6GB big .git dir? (I agree I probably shouldn't focus on that first, and could just try jj first on smaller rpos... But git is already slow enough in there that it's an honest question, I don't need to keep using git there as long as I can keep pulling from stable kernels git trees for regular merges)

It works fine on nixpkgs, which is by some measures larger than the linux git repo.

jj git clone/fetch/push are using the corresponding git commands under the hood so they won't improve on git performance but also it doesn't have much overheard of its own.

If you're using the -T revset syntax, you can specify a revset that requires looking at every commit, which is slow, but that's equivalent to asking for `git log -n 1000000`

Re: Jujutsu Megamerges and jj Absorb

#30

Post by steveklabnik »

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…

You’re making an understandable mistake. Jj being simpler doesn’t mean it is less powerful. It means it’s more powerful. This happens very rarely, but it is the case here. Removing the index and stash as unique concepts doesn’t mean that their use cases disappear: they gain power, because you can use any tool that works on a commit on your “index” or “stash” because they’re also just commits.

I actually like git’s CLI. I never understood why people wanted a simplified git. I’m never going back to git from jj. It’s just better.

Post reply on HN