3 ms·

Many jj commands share names with git commands, yes. That doesn't always mean they do the same exact thing. There's lots that are different too.

ipaddr 2y ago
Sounds like something ready for the mass population.
- steveklabnik 2y ago
  It is true that if you're looking for a finished, polished product, jj is very much not that. It's pre-1.0. Lots of things will change. I still refuse to use anything else these days, but I can understand why someone else might not want to.
- aidenn0 2y ago
  This was true of svn and git; both had command named the same as VCSs that were popular when they were introduced, but had semantics that were subtly (or not so subtly) different.
- KingMob 2y ago
  Unironically, it is. The underlying storage engine is git, which is rock-solid. But to put it this way, I've been using jj for almost a year, and even without a 1.0 release, editor support, or mature tooling, it's still such an improvement over git, I've stopped using git 98% of the time.
lgas 2y ago
> That doesn't always mean they do the same exact thing. There's lots that are different too. That's good. Gotta keep people on their toes.
- steveklabnik 2y ago
  With `jj undo`, it's not a huge deal. I'm (mostly) kidding. jj has to weigh trying to be the best VCS it can be alongside factors like "how much will this confuse someone who's used to git." Both things are important, and balancing them is a tricky process. Take `jj commit` for example. This "does what git commit does," sorta. But also, not really? But if you're five minutes into `jj`, coming from `git`, then yeah, `jj commit` is exactly what you think it is. And that lets you be comfortable. Even though, from the `jj` perspective, it's a very bad name.
ashu1461 2y ago
What is that one popular use case which git does really bad and jj does good ?
- 3eb7988a1663 2y ago
  I am laughing. Fearless merging/rebasing/context switching? Having just one way of doing things? Best to ask the other way around at the current JJ flaws. Which right now would be tooling support and you actually have to be on top of your .gitignore.
- steveklabnik 2y ago
  Virtually everything is easier. How much easier is up for debate. Part of the issue is that everything is interlocking. Small gains in multiple places end up feeling so, so much nicer, even if they may not seem like it. So for example, the index in git is a workflow pattern in jj, not a built in feature. This means that you don't have `git reset` with `--soft` vs `--hard` vs `--mixed`: You just have `jj edit`. This decision also means `jj rebase` can be entirely in memory, which means it's fast. But that wouldn't matter if conflicts weren't a first-class concept in jj, so things like rebase always succeed and immediately. Which doesn't sound like a big deal but you find yourself being able to rebase way more often and way more easily... It's not that git is bad. And it's not that it's bad at a specific thing. It's just that taking some of the other sides of some of the tradeoffs means that you get something that's smaller but also more powerful. And that's cool. I think the "mega merge" plus `jj absorb` might be one of the more flashy things: https://steveklabnik.github.io/jujutsu-tutorial/advanced/simultaneous-edits.html https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... but I don't even do that. The basics are still just nicer.
  - ashenke 2y ago
    So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it. I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it). One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks". I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something

ipaddr 2y ago

Sounds like something ready for the mass population.

steveklabnik 2y ago
It is true that if you're looking for a finished, polished product, jj is very much not that. It's pre-1.0. Lots of things will change. I still refuse to use anything else these days, but I can understand why someone else might not want to.
aidenn0 2y ago
This was true of svn and git; both had command named the same as VCSs that were popular when they were introduced, but had semantics that were subtly (or not so subtly) different.
KingMob 2y ago
Unironically, it is. The underlying storage engine is git, which is rock-solid. But to put it this way, I've been using jj for almost a year, and even without a 1.0 release, editor support, or mature tooling, it's still such an improvement over git, I've stopped using git 98% of the time.

lgas 2y ago

> That doesn't always mean they do the same exact thing. There's lots that are different too. That's good. Gotta keep people on their toes.

steveklabnik 2y ago
With `jj undo`, it's not a huge deal. I'm (mostly) kidding. jj has to weigh trying to be the best VCS it can be alongside factors like "how much will this confuse someone who's used to git." Both things are important, and balancing them is a tricky process. Take `jj commit` for example. This "does what git commit does," sorta. But also, not really? But if you're five minutes into `jj`, coming from `git`, then yeah, `jj commit` is exactly what you think it is. And that lets you be comfortable. Even though, from the `jj` perspective, it's a very bad name.

ashu1461 2y ago

What is that one popular use case which git does really bad and jj does good ?

3eb7988a1663 2y ago
I am laughing. Fearless merging/rebasing/context switching? Having just one way of doing things? Best to ask the other way around at the current JJ flaws. Which right now would be tooling support and you actually have to be on top of your .gitignore.
steveklabnik 2y ago
Virtually everything is easier. How much easier is up for debate. Part of the issue is that everything is interlocking. Small gains in multiple places end up feeling so, so much nicer, even if they may not seem like it. So for example, the index in git is a workflow pattern in jj, not a built in feature. This means that you don't have `git reset` with `--soft` vs `--hard` vs `--mixed`: You just have `jj edit`. This decision also means `jj rebase` can be entirely in memory, which means it's fast. But that wouldn't matter if conflicts weren't a first-class concept in jj, so things like rebase always succeed and immediately. Which doesn't sound like a big deal but you find yourself being able to rebase way more often and way more easily... It's not that git is bad. And it's not that it's bad at a specific thing. It's just that taking some of the other sides of some of the tradeoffs means that you get something that's smaller but also more powerful. And that's cool. I think the "mega merge" plus `jj absorb` might be one of the more flashy things: https://steveklabnik.github.io/jujutsu-tutorial/advanced/simultaneous-edits.html https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... but I don't even do that. The basics are still just nicer.
- ashenke 2y ago
  So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it. I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it). One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks". I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something