5 ms·

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour ru

by palata 1y ago

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff. But you will be infinitely more productive: when you start bim, you're already in edit mode, so you don't have to type i! And the auto-complete in Julia is objectively a lot better in bim!". Sure, but typing "i" a few times more is really not a concern for me, and I don't use Julia. But if it's better for you, please enjoy bim!

stouset 1y ago
For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. I greatly prefer working with (and being) the kind of developer that puts out a large number of very tiny and easy to review PRs, eve. jj makes doing that a breeze. There are lots of people for whom these things aren't important. I will be slightly judgmental and say I don't really enjoy working with them. They tend to write very large PRs that are difficult and time-consuming to review. And it's a frequent source of frustration for everyone when 95% of the work is uncontroversial but a merge is being held up because of legitimate concerns with an unrelated 5%. This is even worse when there's later work that builds upon it that can't happen until a merge (or that needs to be constantly rebased as the PR is improved). This is not to say if you do this you’re a bad developer. There are plenty of great developers who don’t care about these things and still do great work. This is also not to say you can’t follow my preferred approach with git. I did it with git for a decade and a half.
- beng-nl 1y ago
  Wow, that does sound like a big improvement. My git commits are, when not forced to be otherwise, very sloppy, even though I’d prefer them to be neatly self contained. But as you imply, there is friction to making these in git, while making lots of unrelated changes in a single coding session. As an example of another ‘unnecessary’ switch, Pip with venvs was also completely solving all my Python dependency problems. I just needed to copy paste a few lines from my README to create and populate the venv, and remember to run pip and Python from that venv. And run pip freeze after package installs or upgrades. No problem. But switching to uv was a huge life improvement. No more copy pasting (‘uv sync’ does everything and even that isn’t needed) nor remembering extra steps and everything is fast so I’m never waiting and forgetting what I was going to do. I could’ve been GP talking about pip but still I would be missing out. I still see people clinging to cvs because it works for them (netbsd why?), which I respect but don’t understand/believe. Fish don’t know what water is. So.. I’m gonna give jj a go and trust life will be better again.
  - stavros 1y ago
    I'm fairly confident you're going to love it. I'd read a few tutorials, but what finally clicked for me was just asking Claude what commands to use, and then explaining why. Jujutsu finally made me understand git, after ten years of git use. It removes enough of the magic that I now know exactly what the commands do, and how the data model works.
  - nchmy 1y ago
    You'll love jj, as you've already been able to see the the light with new tooling like uv. Jj is to git what uv is to other python tooling. Check out jjui as well, which makes jj even better. https://github.com/idursun/jjui https://github.com/idursun/jjui https://mise.jdx.dev https://mise.jdx.dev is equally as revelatory as jj and uv
    - exographicskip 1y ago
      mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf
IshKebab 1y ago
It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos. There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.
- palata 1y ago
  And I totally agree! And if jj works better for you, please use it! My point is just that I am yet to find a convincing example that would suggest that jj would improve my workflow. If people find it hard to stash a change, I don't tell them that they shouldn't get their shit together and not use jj. But I don't find it hard to stash a change, so why do I feel like jj evangelists try to convince me that something is wrong with me?
  - stavros 1y ago
    This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing things with it that you couldn't be bothered to before. Yes, I can switch branches in git by stashing my changes, and then I can try to figure out the five-levels-deep stash stack, but with jj I just switch between branches without finishing working on them, because it just works and is easy. Yes, with git you can technically have five branches open at the same time, and stash work to switch between them to work on one thing or the other, but it's so hard and finicky that you end up never doing it in reality. Or, you can say "I never need that", but is it that you never need it, or that your tools make it so hard that you just subconsciously never do it? For me, it was the latter, as now I'm switching between branches ALL THE TIME, just because it's easy.
    - nchmy 1y ago
      I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more. The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm syndrome...
whatagreatboy 1y ago
How much time do you spend resolving merge conflicts between multiple team members?
- palata 1y ago
  In good approximation, I would say around 0 minute a week. I guess it could happen that it takes a few minutes, but I don't remember last time it happened.
  - beanjuiceII 1y ago
    yea i am really confused by all these issues people are saying they have myself..stashing merging etc...and what is crazy is we migrated large teams of programmers who's only experience with version control before git was microsoft TFS and and everyone is easily and happily chugging along. Now most of these people use gui tooling for managing git, but so what everyone gets it done with no issues or complaints with many projects big and small. we even have non-devs using it. I get jj might have some life improvements for some niche groups of people but i really have to wonder if they are the type of people who purposely make their life more complex
- nchmy 1y ago
  Forget between team members - it's an issue just for my own local dev purposes, when I'm working on multiple changes/PRs at the same time and want to test them all out before they get merged to main in the origin.
voidfunc 1y ago
I use like five commands total in Git and the rest is driven through my IDE which handles everything else. People who tell me Git is hard or recommend alternate tools are living in a different world.
DrBazza 1y ago
>I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it. jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs want git, my colleagues know git, I'll be asked a question about... git. Using git has been the lowest version control churn in my brain for a decade, which is nice.
- edanm 1y ago
  I mean, Git was a massive improvement over those other systems though. It was absolutely worth learning, and worth pushing companies to adopt. (Same with Mercurial, obviously.)
- stouset 1y ago
  I still know git. I work at entirely git shops. Nobody has ever come to me with a problem I’ve caused, but people have come to me to ask how to switch. I am also the guy who gets asked with doing crazy git things when the need comes up. I have another post here where a tricky and slow filter-branch that our company needed to do on a repo was a simple and obvious three-liner in jj.
- BeetleB 1y ago
  > Jobs want git, my colleagues know git And outside of a few scenarios, they can use git, you can use jj, and everyone will be happy. I push to my team's Git repo using jj all the time.
benoau 1y ago
> You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff Wit the added bonus that "bim" won't remain popular enough to sustain its development for long, so "bim" users have to switch to the fork "bbim" in 2 years, that won't remain popular enough to sustain its development for long...
kyawzazaw 1y ago
I feel like it's cat vs bat. bat just is more useful even if you didn't have issues with cat
dcre 1y ago
This is also true of vim. You have to move to Helix. It's very similar to vim, but different enough that you have to learn new stuff.
nswest23 1y ago
How do you know? Maybe jj would be a productivity improvement for you. Maybe it wouldn't. There's only one way to find out and it seems like a pretty painless thing to try. If this is your attitude toward new things do you still pump water out of a well when you're thirsty?
palata 1y ago
Actually I find this tutorial to make a really good point in introducing it Jujutsu [1] without implying that "if you don't know it you don't know the Truth/haven't seen the light/are a peasant". The author starts by saying that they actually have no issue with the git CLI, which is exactly my case. I started trying jujutsu and until now, I can describe the feeling as an ergonomic keyboard: I am fine with any keyboard, really, it's not that some keyboards are "hard to use". Nobody would (should?) say "with a cheap keyboard, you can't type fast enough to be efficient, but with this ergonomic keyboard, you will be faster". But one may find that an ergonomic keyboard is more comfortable for them, or that it sounds a bit better or feel a bit better. There is no real need to change keyboard if you like yours. It doesn't mean that it's impossible to find another keyboard that would be more pleasant to use. JJ may be that (for me, but again I'm just starting): it seems equivalent to git CLI (as in, it's not a heavy GUI or a VScode plugin: it's really a CLI) and it feels like it may be more ergonomic. And at the very least, it's fun to try. [1]: https://steveklabnik.github.io/jujutsu-tutorial/ https://steveklabnik.github.io/jujutsu-tutorial/

by palata 1y ago

stouset 1y ago

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. I greatly prefer working with (and being) the kind of developer that puts out a large number of very tiny and easy to review PRs, eve. jj makes doing that a breeze. There are lots of people for whom these things aren't important. I will be slightly judgmental and say I don't really enjoy working with them. They tend to write very large PRs that are difficult and time-consuming to review. And it's a frequent source of frustration for everyone when 95% of the work is uncontroversial but a merge is being held up because of legitimate concerns with an unrelated 5%. This is even worse when there's later work that builds upon it that can't happen until a merge (or that needs to be constantly rebased as the PR is improved). This is not to say if you do this you’re a bad developer. There are plenty of great developers who don’t care about these things and still do great work. This is also not to say you can’t follow my preferred approach with git. I did it with git for a decade and a half.

beng-nl 1y ago
Wow, that does sound like a big improvement. My git commits are, when not forced to be otherwise, very sloppy, even though I’d prefer them to be neatly self contained. But as you imply, there is friction to making these in git, while making lots of unrelated changes in a single coding session. As an example of another ‘unnecessary’ switch, Pip with venvs was also completely solving all my Python dependency problems. I just needed to copy paste a few lines from my README to create and populate the venv, and remember to run pip and Python from that venv. And run pip freeze after package installs or upgrades. No problem. But switching to uv was a huge life improvement. No more copy pasting (‘uv sync’ does everything and even that isn’t needed) nor remembering extra steps and everything is fast so I’m never waiting and forgetting what I was going to do. I could’ve been GP talking about pip but still I would be missing out. I still see people clinging to cvs because it works for them (netbsd why?), which I respect but don’t understand/believe. Fish don’t know what water is. So.. I’m gonna give jj a go and trust life will be better again.
- stavros 1y ago
  I'm fairly confident you're going to love it. I'd read a few tutorials, but what finally clicked for me was just asking Claude what commands to use, and then explaining why. Jujutsu finally made me understand git, after ten years of git use. It removes enough of the magic that I now know exactly what the commands do, and how the data model works.
- nchmy 1y ago
  You'll love jj, as you've already been able to see the the light with new tooling like uv. Jj is to git what uv is to other python tooling. Check out jjui as well, which makes jj even better. https://github.com/idursun/jjui https://github.com/idursun/jjui https://mise.jdx.dev https://mise.jdx.dev is equally as revelatory as jj and uv
  - exographicskip 1y ago
    mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf

IshKebab 1y ago

It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos. There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.

palata 1y ago
And I totally agree! And if jj works better for you, please use it! My point is just that I am yet to find a convincing example that would suggest that jj would improve my workflow. If people find it hard to stash a change, I don't tell them that they shouldn't get their shit together and not use jj. But I don't find it hard to stash a change, so why do I feel like jj evangelists try to convince me that something is wrong with me?
- stavros 1y ago
  This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing things with it that you couldn't be bothered to before. Yes, I can switch branches in git by stashing my changes, and then I can try to figure out the five-levels-deep stash stack, but with jj I just switch between branches without finishing working on them, because it just works and is easy. Yes, with git you can technically have five branches open at the same time, and stash work to switch between them to work on one thing or the other, but it's so hard and finicky that you end up never doing it in reality. Or, you can say "I never need that", but is it that you never need it, or that your tools make it so hard that you just subconsciously never do it? For me, it was the latter, as now I'm switching between branches ALL THE TIME, just because it's easy.
  - nchmy 1y ago
    I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more. The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm syndrome...

whatagreatboy 1y ago

How much time do you spend resolving merge conflicts between multiple team members?

palata 1y ago
In good approximation, I would say around 0 minute a week. I guess it could happen that it takes a few minutes, but I don't remember last time it happened.
- beanjuiceII 1y ago
  yea i am really confused by all these issues people are saying they have myself..stashing merging etc...and what is crazy is we migrated large teams of programmers who's only experience with version control before git was microsoft TFS and and everyone is easily and happily chugging along. Now most of these people use gui tooling for managing git, but so what everyone gets it done with no issues or complaints with many projects big and small. we even have non-devs using it. I get jj might have some life improvements for some niche groups of people but i really have to wonder if they are the type of people who purposely make their life more complex
nchmy 1y ago
Forget between team members - it's an issue just for my own local dev purposes, when I'm working on multiple changes/PRs at the same time and want to test them all out before they get merged to main in the origin.

voidfunc 1y ago

I use like five commands total in Git and the rest is driven through my IDE which handles everything else. People who tell me Git is hard or recommend alternate tools are living in a different world.

DrBazza 1y ago

>I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it. jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs want git, my colleagues know git, I'll be asked a question about... git. Using git has been the lowest version control churn in my brain for a decade, which is nice.

edanm 1y ago
I mean, Git was a massive improvement over those other systems though. It was absolutely worth learning, and worth pushing companies to adopt. (Same with Mercurial, obviously.)
stouset 1y ago
I still know git. I work at entirely git shops. Nobody has ever come to me with a problem I’ve caused, but people have come to me to ask how to switch. I am also the guy who gets asked with doing crazy git things when the need comes up. I have another post here where a tricky and slow filter-branch that our company needed to do on a repo was a simple and obvious three-liner in jj.
BeetleB 1y ago
> Jobs want git, my colleagues know git And outside of a few scenarios, they can use git, you can use jj, and everyone will be happy. I push to my team's Git repo using jj all the time.

benoau 1y ago

> You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff Wit the added bonus that "bim" won't remain popular enough to sustain its development for long, so "bim" users have to switch to the fork "bbim" in 2 years, that won't remain popular enough to sustain its development for long...

kyawzazaw 1y ago

I feel like it's cat vs bat. bat just is more useful even if you didn't have issues with cat

dcre 1y ago

This is also true of vim. You have to move to Helix. It's very similar to vim, but different enough that you have to learn new stuff.

nswest23 1y ago

How do you know? Maybe jj would be a productivity improvement for you. Maybe it wouldn't. There's only one way to find out and it seems like a pretty painless thing to try. If this is your attitude toward new things do you still pump water out of a well when you're thirsty?

palata 1y ago

Actually I find this tutorial to make a really good point in introducing it Jujutsu [1] without implying that "if you don't know it you don't know the Truth/haven't seen the light/are a peasant". The author starts by saying that they actually have no issue with the git CLI, which is exactly my case. I started trying jujutsu and until now, I can describe the feeling as an ergonomic keyboard: I am fine with any keyboard, really, it's not that some keyboards are "hard to use". Nobody would (should?) say "with a cheap keyboard, you can't type fast enough to be efficient, but with this ergonomic keyboard, you will be faster". But one may find that an ergonomic keyboard is more comfortable for them, or that it sounds a bit better or feel a bit better. There is no real need to change keyboard if you like yours. It doesn't mean that it's impossible to find another keyboard that would be more pleasant to use. JJ may be that (for me, but again I'm just starting): it seems equivalent to git CLI (as in, it's not a heavy GUI or a VScode plugin: it's really a CLI) and it feels like it may be more ergonomic. And at the very least, it's fun to try. [1]: https://steveklabnik.github.io/jujutsu-tutorial/ https://steveklabnik.github.io/jujutsu-tutorial/