7 ms·

There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact

There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control. If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down, maybe the same will happen with git. 2. jj today I use jj today and the biggest advantages for me are not needing to worry as much about the order of operations. I write some code and then I come across a bug. I can pull out the bug and fix it while still working on my existing code. I don't have to go back in time to fix it. I also appreciate not needing to stop just because of a conflict. This is something I miss from SVN, which was similar-ish in that conflicts didn't need to be addressed immediately, only jj's implementation is better. Generally I find the jj workflow to be something that takes a few days of adjustment, then it just makes more sense. 3. The way things will be jj is still relatively early. The commands to interact with git aren't all very intuitive or easy to use. I had to make some aliases to make this easier. More importantly, there's no jj backend yet. Once that happens and it's adopted by forgjo or another forge (Gitlab, Github), I think we'll see a big shift towards it. I think git is going to be around a long time, but the day to day use of jj is so much nicer than git that I hope it will gain fast adoption.

yuppiepuppie 2y ago
I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. Yes, I know that some code bases are too far gone for major enhancements…
- rakoo 2y ago
  If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible
- KerrAvon 2y ago
  Think of it this way: they are trying to make git better by addressing fundamental weaknesses in git, but some of those weaknesses require a fundamentally different UI paradigm and as such aren’t practical to upstream, hence a new project.
- skybrian 2y ago
  In some sense they already are making git better since that’s the data format that the tool supports. Also, some of the UI improvements or even protocol improvements might make it into git eventually. I’m skeptical about it being worthwhile to switch to a new backend. Maybe it would work if it’s just local, but a lot of IDE plugins and other tools would need to be written, and git has lots of inertia.
- dietr1ch 2y ago
  > why would the contributors to jj not just try to make git better by addressing these weaknesses? Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.
  - martinvonz 2y ago
    This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.
    - dietr1ch 2y ago
      I thought it was simply a response to git5/git-multi getting deprecated once fig became popular. I'm a bit surprised then, that's one of the things that has kept me from trying it as it feels weird to not have that much control over what gets into the commit. Using magit doesn't help as it's just way too good once you get used to it.
- BrouteMinou 2y ago
  [flagged]
- keybored 2y ago
  > I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. You would have thought? Plugins? Git doesn’t have plugins to my knowledge. Hooks are not plugins for security reasons. Meaning you can’t distribute hooks, have people install them and call it an extension. Then, assuming that they could just make Git better. Are they interested in supporting all of Git plus their new work? Why would they be?
- stouset 2y ago
  > However, why would the contributors to jj not just try to make git better by addressing these weaknesses? Because the git workflow causes a lot of the difficulty and fixing it involves making a new concept: mutable changesets with a unique id which are built on top of immutable commits. jj isn’t just some bugfixes or a few porcelain improvements, it deeply changes the way you approach things. And there’s a pretty decent amount of unlearning of subtly-broken concepts you need to do. None of that could ever make its way into git.
KerrAvon 2y ago
Merges were so, so painful in SVN, though. Maybe SVN improved towards the end of its life? I remember everyone went well out of their way to avoid needing to merge until git, because it could take hours to resolve a heavily-conflicted tree.
- stouset 2y ago
  People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use. But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.
  - yuppiepuppie 2y ago
    Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org. My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.
    - stouset 2y ago
      > to introduce an un proven tool to an org Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them. I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commit/merge-to-main approach and people still constantly run into problems. None of the people with some claimed simple workflow are doing anything meaningfully different than what everyone else is doing. It’s just astonishingly easy to internalize all the fixes and band aids we’ve adopted to smooth the sharp edges and forget how often we have to work around them.
      - 2y ago
sebastialonso 2y ago
Point 3 is dishonest, imo. jj has no evidence today to support the idea that it will be a main tool in the future. An even heavier burden of proof comes from the idea that it could be adopted by mainstream forges, so it's certainly not an argument on how jj is better than git.
JTyQZSnP3cQGa8B 2y ago
> 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.

yuppiepuppie 2y ago

I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. Yes, I know that some code bases are too far gone for major enhancements…

rakoo 2y ago
If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible
KerrAvon 2y ago
Think of it this way: they are trying to make git better by addressing fundamental weaknesses in git, but some of those weaknesses require a fundamentally different UI paradigm and as such aren’t practical to upstream, hence a new project.
skybrian 2y ago
In some sense they already are making git better since that’s the data format that the tool supports. Also, some of the UI improvements or even protocol improvements might make it into git eventually. I’m skeptical about it being worthwhile to switch to a new backend. Maybe it would work if it’s just local, but a lot of IDE plugins and other tools would need to be written, and git has lots of inertia.
dietr1ch 2y ago
> why would the contributors to jj not just try to make git better by addressing these weaknesses? Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.
- martinvonz 2y ago
  This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.
  - dietr1ch 2y ago
    I thought it was simply a response to git5/git-multi getting deprecated once fig became popular. I'm a bit surprised then, that's one of the things that has kept me from trying it as it feels weird to not have that much control over what gets into the commit. Using magit doesn't help as it's just way too good once you get used to it.
BrouteMinou 2y ago
[flagged]
keybored 2y ago
> I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. You would have thought? Plugins? Git doesn’t have plugins to my knowledge. Hooks are not plugins for security reasons. Meaning you can’t distribute hooks, have people install them and call it an extension. Then, assuming that they could just make Git better. Are they interested in supporting all of Git plus their new work? Why would they be?
stouset 2y ago
> However, why would the contributors to jj not just try to make git better by addressing these weaknesses? Because the git workflow causes a lot of the difficulty and fixing it involves making a new concept: mutable changesets with a unique id which are built on top of immutable commits. jj isn’t just some bugfixes or a few porcelain improvements, it deeply changes the way you approach things. And there’s a pretty decent amount of unlearning of subtly-broken concepts you need to do. None of that could ever make its way into git.

KerrAvon 2y ago

Merges were so, so painful in SVN, though. Maybe SVN improved towards the end of its life? I remember everyone went well out of their way to avoid needing to merge until git, because it could take hours to resolve a heavily-conflicted tree.

stouset 2y ago
People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use. But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.
- yuppiepuppie 2y ago
  Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org. My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.
  - stouset 2y ago
    > to introduce an un proven tool to an org Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them. I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commit/merge-to-main approach and people still constantly run into problems. None of the people with some claimed simple workflow are doing anything meaningfully different than what everyone else is doing. It’s just astonishingly easy to internalize all the fixes and band aids we’ve adopted to smooth the sharp edges and forget how often we have to work around them.
    - 2y ago

sebastialonso 2y ago

Point 3 is dishonest, imo. jj has no evidence today to support the idea that it will be a main tool in the future. An even heavier burden of proof comes from the idea that it could be adopted by mainstream forges, so it's certainly not an argument on how jj is better than git.

JTyQZSnP3cQGa8B 2y ago

> 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.