5 ms·

At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone,

by kelnos 1y ago

At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think. Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.

steveklabnik 1y ago
I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use. The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move. I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
- jimbokun 1y ago
  One thing not mentioned in the article: what advantages does jj offer over plain git?
  - steveklabnik 1y ago
    So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
    - jimbokun 1y ago
      So better UX while keeping git's solid internals? Makes sense. Developers I know have been wanting that.
      - steveklabnik 1y ago
        It's technically a bit more than that. JJ is its own VCS, with pluggable backends. Google has a closed-source Piper backend, the git backend is the only real open source backend. But at high level, it's fine to think about it in that way, yeah. I tend to think about it as being more "able to work on git repos" than as a UI.
        warwren 1y ago
        I can't hear Piper backend without thinking about Pied Piper
      - SoftTalker 1y ago
        Not the only project that's working on that. https://www.gameoftrees.org/ https://www.gameoftrees.org/
    - 1y ago
- kelnos 1y ago
  Sure, definitely, sorry for being a bit off-topic, clearly this was about you and your plans and not intended to be about jj itself. Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX. And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.
pythonaut_16 1y ago
Fair points. I'm also generally happy with Git myself. I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits). Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
jakub_g 1y ago
The good thing is that a new player entering the arena allows a fresh look at certain problems, and some solutions then get backported to the OG project. I've read it already happened that jj inspired some changes in git. Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.
baq 1y ago
I used to think this, too. Tried jj a few times before it clicked. It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.
weinzierl 1y ago
I used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind. For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
- riffraff 1y ago
  May I ask what is your rebase workflow at work? In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
  - weinzierl 1y ago
    Basically the same except in some projects we are not supposed to squash. So, sometimes we end up with long long histories to be rebased onto other long histories. rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
dxdm 1y ago
I think yours a perfectly reasonable stance, and I often feel the same way. And all this complaining about git is getting tiresome, especially if you had to deal with its predecessors. FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works. Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone. And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.
kzrdude 1y ago
I learned all of cvs, svn and then later git when getting into Linux and Open Source. Based on my early experience of multiple systems, I'm very surprised that git has dominated and lasted this long already!
jrockway 1y ago
jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts. I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane. To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away. Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
- constantius 1y ago
  I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually. Do I understand correctly that jj does it automatically?
  - steveklabnik 1y ago
    That's correct, it will do the cascade rebase of everything automatically.
    - constantius 1y ago
      Thanks Steve, and for the tutorial too!
kolme 1y ago
I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git. You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on. There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
- turtlebits 1y ago
  Ergonomics are everything. Its why there are zillion IDEs, terminal apps, keyboards, mice, etc. Hot take, but I personally hate git and almost always rely on a GUI tool or IDE integration to interact with it.
- dagenix 1y ago
  One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
- ahaferburg 1y ago
  You don't need to switch from git to jj. You just try out jj on your git project and see if it clicks. If you don't like it, you just don't continue using it.
jauntywundrkind 1y ago
I personally feel quite capable at git and am not looking for another flow or tool. But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history. (I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.) I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.

by kelnos 1y ago

steveklabnik 1y ago

I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use. The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move. I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.

jimbokun 1y ago
One thing not mentioned in the article: what advantages does jj offer over plain git?
- steveklabnik 1y ago
  So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
  - jimbokun 1y ago
    So better UX while keeping git's solid internals? Makes sense. Developers I know have been wanting that.
    - steveklabnik 1y ago
      It's technically a bit more than that. JJ is its own VCS, with pluggable backends. Google has a closed-source Piper backend, the git backend is the only real open source backend. But at high level, it's fine to think about it in that way, yeah. I tend to think about it as being more "able to work on git repos" than as a UI.
      - warwren 1y ago
        I can't hear Piper backend without thinking about Pied Piper
    - SoftTalker 1y ago
      Not the only project that's working on that. https://www.gameoftrees.org/ https://www.gameoftrees.org/
  - 1y ago
kelnos 1y ago
Sure, definitely, sorry for being a bit off-topic, clearly this was about you and your plans and not intended to be about jj itself. Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX. And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.

pythonaut_16 1y ago

Fair points. I'm also generally happy with Git myself. I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits). Stacked PRs also look interesting but I haven't had an occasion to try them out yet.

jakub_g 1y ago

The good thing is that a new player entering the arena allows a fresh look at certain problems, and some solutions then get backported to the OG project. I've read it already happened that jj inspired some changes in git. Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.

baq 1y ago

I used to think this, too. Tried jj a few times before it clicked. It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.

weinzierl 1y ago

I used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind. For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back

riffraff 1y ago
May I ask what is your rebase workflow at work? In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
- weinzierl 1y ago
  Basically the same except in some projects we are not supposed to squash. So, sometimes we end up with long long histories to be rebased onto other long histories. rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.

dxdm 1y ago

I think yours a perfectly reasonable stance, and I often feel the same way. And all this complaining about git is getting tiresome, especially if you had to deal with its predecessors. FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works. Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone. And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.

kzrdude 1y ago

I learned all of cvs, svn and then later git when getting into Linux and Open Source. Based on my early experience of multiple systems, I'm very surprised that git has dominated and lasted this long already!

jrockway 1y ago

jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts. I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane. To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away. Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.

constantius 1y ago
I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually. Do I understand correctly that jj does it automatically?
- steveklabnik 1y ago
  That's correct, it will do the cascade rebase of everything automatically.
  - constantius 1y ago
    Thanks Steve, and for the tutorial too!

kolme 1y ago

I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git. You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on. There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?

turtlebits 1y ago
Ergonomics are everything. Its why there are zillion IDEs, terminal apps, keyboards, mice, etc. Hot take, but I personally hate git and almost always rely on a GUI tool or IDE integration to interact with it.
dagenix 1y ago
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
ahaferburg 1y ago
You don't need to switch from git to jj. You just try out jj on your git project and see if it clicks. If you don't like it, you just don't continue using it.

jauntywundrkind 1y ago

I personally feel quite capable at git and am not looking for another flow or tool. But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history. (I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.) I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.