3 ms·

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

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 really convey the full weight of this without a long explanation, because people are so used to thinking in git, it takes a long time to go beyond "so rebase -i will be faster, then? But it's not slow, is it?" It's funny, that git is now in the position that subversion was in almost two decades ago: People were so used to svn and felt productive with it, it was hard to convey why free branches and a distributed data model are a gamechanger, and how much svn limited their thinking. But as a git user you had certainty that you were right, and that your tool is superior. Now, people are so used to git, in an eerily similar way. But ask most git users, "how would you move a specific change from your branch to another?" I have yet to receive a confident answer and workflow to this (they do exist ofc), the common reaction I get is that this isn't something they'd ever need anyways. I'm curious how this will look in a few years :)

bayindirh 2y ago
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 use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways. svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.
- Certhas 2y ago
  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.
  - bayindirh 2y ago
    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.
dijit 2y ago
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.
williamdclt 2y ago
> 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
- stouset 2y ago
  Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.
  - williamdclt 2y ago
    The downside part is "it is not an area where I have capacity or willingness to innovate". I'd happily follow, I don't care enough to lead the innovation.
  - Macha 2y ago
    Yeah, this is the real advantage that jj (and sapling) have compared to how many years I'd been hearing about fossil and seeing it as a non-starter to experiment with.

bayindirh 2y ago

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 use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways. svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.

Certhas 2y ago
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.
- bayindirh 2y ago
  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.

dijit 2y ago

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.

williamdclt 2y ago

> 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

stouset 2y ago
Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.
- williamdclt 2y ago
  The downside part is "it is not an area where I have capacity or willingness to innovate". I'd happily follow, I don't care enough to lead the innovation.
- Macha 2y ago
  Yeah, this is the real advantage that jj (and sapling) have compared to how many years I'd been hearing about fossil and seeing it as a non-starter to experiment with.