4 ms·

> I remember plenty of people who used SVN saying why did they need to use git I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easil

> I remember plenty of people who used SVN saying why did they need to use git I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easily create branches.” Also mixed revisions which was the worst part of it. The jj people should really write a guide to show how it’s better than git because, so far, I’m still very confused and we’ve had that conversation on HN at least 10 times without anyone giving concrete examples.

stouset 2y ago
And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once. I’ll give you some concrete advantages: 1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I have an idea for a slightly different approach, try it out, it doesn’t pan out, and I’m like fuck I wish I’d saved where I was an hour ago. git won’t do that for you but jj will. 2. The rebase workflow is dramatically better. Rebasing multiple commits with conflicts is excruciating. You have to fix it right here and right now but you’re in a weird repo state where you can’t easily to another commit and tweak it or look at the state of things at different times. It’s a pain in the ass and easy to get wrong. With jj there are no weird intermediate rebase states. Rebasing always succeeds and if there are conflicts you’re able to address them just by editing your changes as you would in any other situation. 3. I don’t have to make WIP commits or stash when switching between lines of work and I don’t have to remember to undo them when I come back. Your work is always committed. Stashing doesn’t need to exist any more and as a result I never have to worry about conflicts when unstashing. I never have to realize I’ve forgotten work that was stashed. 4. Named branches don’t follow you automatically. This is huge if you ever have to do some linear work that involves multiple PRs that have to be merged and deployed one by one by one. With git you have to make branch after branch after branch. And god help you if one of the earlier lines of work needs to be changed, now you have to rebase all the descendants. With jj all this work is linear. If you have to edit an earlier commit or insert a new commit inbetween two, it’s trivial. 5. And the real killer feature? I get to have all this and nobody on my team needed to change a thing for themselves. I was a git expert. I’ve used it since before GitHub. I’ve written a barebones implementation of git from scratch. I was the guy everyone came to when they got stuck. I gave talks on git to my local language user meetup. And I will never need to touch it again.
- dsissitka 2y ago
  > Every time you run a `jj` command a snapshot of your local changes is made. I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.
  - deleted 2y ago
    [deleted]
  - steveklabnik 2y ago
    I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.
    - dsissitka 2y ago
      > The auto add feature is configurable these days though, so if you don’t like it, you can turn it off. That's one of the workarounds I had in mind. :) This week I've had to work with CSVs, SQLite databases, and video in... six... different formats. Some goes in the repo, some doesn't. It seems like my choices are: - Disable it in the repo's .jj/repo/config.toml. - Get people that don't like it to turn it off. - Get people to do their exploratory coding in a gitignored directory. It feels like any choice I make is going to be met with resistance.
      - stouset 2y ago
        You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.
steveklabnik 2y ago
For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by having more cohesive primitives. Take the index. I love(d) git’s index. It is a powerful way to build up focused commits. Jj does away with the index, yet gives you equivalent power. How? Because instead of a separate index concept, jj has a special name for a commit representing the index: @. Files are (by default) automatically tracked and included in @. Just like how you’d git add -p, you create a new commit for your work, then create a commit on top of it. As you work, @ gets built up with your code, and when you’re ready, jj squash (with various flags or paths to control exactly what gets added) to move them into your parent, “real” work commit. So if it’s the same, why is it better? Because we’ve reduced the number of states: instead of dirty, staged, and committed, you just have committed. And with that, commands are simpler: no distinction between —hard or —soft for something like git reset, everything just operates on committed state. This means you can bring the full set of tools to manipulate commits to bear on your index! The same goes with stashing: because heads are allowed to be detached, to use the git terminology, we don’t need a special stash concept: create a new commit that’s forward of where you’re working to “stash” your changes in there until you need them. These are two simple examples, but it’s really about how everything fits together into an extremely powerful and cohesive tool.
jjj123 2y ago
The post you’re replying to gave 2 concrete examples.

stouset 2y ago

And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once. I’ll give you some concrete advantages: 1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I have an idea for a slightly different approach, try it out, it doesn’t pan out, and I’m like fuck I wish I’d saved where I was an hour ago. git won’t do that for you but jj will. 2. The rebase workflow is dramatically better. Rebasing multiple commits with conflicts is excruciating. You have to fix it right here and right now but you’re in a weird repo state where you can’t easily to another commit and tweak it or look at the state of things at different times. It’s a pain in the ass and easy to get wrong. With jj there are no weird intermediate rebase states. Rebasing always succeeds and if there are conflicts you’re able to address them just by editing your changes as you would in any other situation. 3. I don’t have to make WIP commits or stash when switching between lines of work and I don’t have to remember to undo them when I come back. Your work is always committed. Stashing doesn’t need to exist any more and as a result I never have to worry about conflicts when unstashing. I never have to realize I’ve forgotten work that was stashed. 4. Named branches don’t follow you automatically. This is huge if you ever have to do some linear work that involves multiple PRs that have to be merged and deployed one by one by one. With git you have to make branch after branch after branch. And god help you if one of the earlier lines of work needs to be changed, now you have to rebase all the descendants. With jj all this work is linear. If you have to edit an earlier commit or insert a new commit inbetween two, it’s trivial. 5. And the real killer feature? I get to have all this and nobody on my team needed to change a thing for themselves. I was a git expert. I’ve used it since before GitHub. I’ve written a barebones implementation of git from scratch. I was the guy everyone came to when they got stuck. I gave talks on git to my local language user meetup. And I will never need to touch it again.

dsissitka 2y ago
> Every time you run a `jj` command a snapshot of your local changes is made. I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.
- deleted 2y ago
  [deleted]
- steveklabnik 2y ago
  I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.
  - dsissitka 2y ago
    > The auto add feature is configurable these days though, so if you don’t like it, you can turn it off. That's one of the workarounds I had in mind. :) This week I've had to work with CSVs, SQLite databases, and video in... six... different formats. Some goes in the repo, some doesn't. It seems like my choices are: - Disable it in the repo's .jj/repo/config.toml. - Get people that don't like it to turn it off. - Get people to do their exploratory coding in a gitignored directory. It feels like any choice I make is going to be met with resistance.
    - stouset 2y ago
      You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.

steveklabnik 2y ago

For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by having more cohesive primitives. Take the index. I love(d) git’s index. It is a powerful way to build up focused commits. Jj does away with the index, yet gives you equivalent power. How? Because instead of a separate index concept, jj has a special name for a commit representing the index: @. Files are (by default) automatically tracked and included in @. Just like how you’d git add -p, you create a new commit for your work, then create a commit on top of it. As you work, @ gets built up with your code, and when you’re ready, jj squash (with various flags or paths to control exactly what gets added) to move them into your parent, “real” work commit. So if it’s the same, why is it better? Because we’ve reduced the number of states: instead of dirty, staged, and committed, you just have committed. And with that, commands are simpler: no distinction between —hard or —soft for something like git reset, everything just operates on committed state. This means you can bring the full set of tools to manipulate commits to bear on your index! The same goes with stashing: because heads are allowed to be detached, to use the git terminology, we don’t need a special stash concept: create a new commit that’s forward of where you’re working to “stash” your changes in there until you need them. These are two simple examples, but it’s really about how everything fits together into an extremely powerful and cohesive tool.

jjj123 2y ago

The post you’re replying to gave 2 concrete examples.