5 ms·

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre me

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Given all the downstream effects, I do not think introducing another VCS is a net positive.

ahartmetz 1y ago
In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".
- jtwaleson 1y ago
  I do see that, and git is not perfect, not by a long shot. I'd much rather see an evolution of git itself rather than getting more alternatives.
  - louistsi 1y ago
    That essentially is what jj is though, given it can be used on git repositories transparently.
KingMob 1y ago
Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git. Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).
a022311 1y ago
As far as I can tell, jj intends to be more like a cross-VCS frontend (with their own native backend coming at some point). If tooling supports jj, it would automatically support git, jj's native backend, Google's hybrid backend and any other backend a user could add.
- jtwaleson 1y ago
  https://xkcd.com/927/ https://xkcd.com/927/ (and now we have 15 standards)
fsw 1y ago
We had rcs, cvs, svn, and now git. Why would it be the ultimate VCS and not be replaced again by something better?
- jtwaleson 1y ago
  If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else. I highly doubt that new tools will be 10x better than git. Maybe 20%?
  - ratrocket 1y ago
    One way I compare the git to jj transition (if it happens, or for whom it happens) to the svn to git transition is: branching in svn was awful. It was heavyweight and you were signing up for pain later down the road. Git made branching easy and normal, almost something you barely need to think about. jj does a similar thing for rebasing. For someone whose familiarity with git is clone, pull, push, merge, creating branches (so, basic/working/practical familiarity but even "rebase -i" might be pushing the limits)- for someone like that what jj offers is a similar "lift" of a feature (rebase) from "scary" to "normal" similar to what git did for branching compared to svn. That's just one aspect of the whole thing, and of course if you're a git rebase wizard (or have tools that make you that) then this won't seem relevant. But I think for a lot of people this might be a salient point.
  - mpalmer 1y ago
    You should really try it; it's clear you're learning some things about it just from this thread. Will a product that is 10x better see rapid adoption if people who have not used it still choose to criticize it in the abstract?
    - jtwaleson 1y ago
      I'm happy to give it a try when I have some time, but I have 0 problems with git right now so it's not top of my list. My critique is also really not towards jj specifically, I'm just discussing the idea that git has extremely wide adoption now and that this has benefits :)
miki123211 1y ago
It's important that jj (the local VCS) is fully compatible with Git (the protocol / interoperability standard). I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.
CGamesPlay 1y ago
I started using git when my employer still used svn. This was possible because `git-svn` was so good and it seamlessly allowed me to use branches to do development while still committing to svn's trunk. I think jj is trying to do something similar: jj-unaware tools work reasonably well in colocated jj repositories, and jj-unaware peers (CI tools, etc) work exactly as they did before. I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.
mpalmer 1y ago
More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Not true. Using jj is a choice made by a single developer. Nothing proprietary escapes from a jj clone of a git repo. Junior devs can use vanilla git if they really want to. All the tooling that works with e.g. repo analysis will need to start supporting git and jj Also not true, unless I misunderstand what you mean by repo analysis. Colocated jj repos are more or less supersets of git repos.
- jtwaleson 1y ago
  I see what you mean, and having looked a bit more deeply today, it's clear that jj is very compatible. However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Windows and Linux (Debian, Arch, Ubuntu, etc). Teams do it, and it's all possible, but it was nice that at least everyone used git.
  - deleted 1y ago
    [deleted]
  - mpalmer 1y ago
    If a team has members who unilaterally rewrite best practice docs to include their preferred technologies, the fault is not with the tech.
    - jtwaleson 1y ago
      I didn't pick a great example and didn't explain it eloquently, but I hope you understand my point. Supporting multiple ways of working takes effort.
CuriouslyC 1y ago
Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch. The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.
- mpalmer 1y ago
  I have no idea what problem this is supposed to solve. Where is the V in VCS here? How do you track the provenance/history of changes? You may not be "forcing" developers to "screw with a graph" (what?) but you are forcing them to screw with macros (we're adding a built-in scripting layer to the VCS?) and these unfamiliar new concepts called atoms and plans. > A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans) And it would introduce zero new confusing issues of its own? > This would also [...] make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch. This is a weird use case. Version control systems aren't typically used for storing and swapping around bits of functionality as a first-class, ongoing concern. Not to mention you still need to figure out how atoms get stitched together. How do you do it without diff-based patches? No superior solution exists, AFAIK. tl;dr use workspaces if you're using agents.
  - CuriouslyC 1y ago

ahartmetz 1y ago

In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".

jtwaleson 1y ago
I do see that, and git is not perfect, not by a long shot. I'd much rather see an evolution of git itself rather than getting more alternatives.
- louistsi 1y ago
  That essentially is what jj is though, given it can be used on git repositories transparently.

KingMob 1y ago

Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git. Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).

a022311 1y ago

As far as I can tell, jj intends to be more like a cross-VCS frontend (with their own native backend coming at some point). If tooling supports jj, it would automatically support git, jj's native backend, Google's hybrid backend and any other backend a user could add.

jtwaleson 1y ago
https://xkcd.com/927/ https://xkcd.com/927/ (and now we have 15 standards)

fsw 1y ago

We had rcs, cvs, svn, and now git. Why would it be the ultimate VCS and not be replaced again by something better?

jtwaleson 1y ago
If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else. I highly doubt that new tools will be 10x better than git. Maybe 20%?
- ratrocket 1y ago
  One way I compare the git to jj transition (if it happens, or for whom it happens) to the svn to git transition is: branching in svn was awful. It was heavyweight and you were signing up for pain later down the road. Git made branching easy and normal, almost something you barely need to think about. jj does a similar thing for rebasing. For someone whose familiarity with git is clone, pull, push, merge, creating branches (so, basic/working/practical familiarity but even "rebase -i" might be pushing the limits)- for someone like that what jj offers is a similar "lift" of a feature (rebase) from "scary" to "normal" similar to what git did for branching compared to svn. That's just one aspect of the whole thing, and of course if you're a git rebase wizard (or have tools that make you that) then this won't seem relevant. But I think for a lot of people this might be a salient point.
- mpalmer 1y ago
  You should really try it; it's clear you're learning some things about it just from this thread. Will a product that is 10x better see rapid adoption if people who have not used it still choose to criticize it in the abstract?
  - jtwaleson 1y ago
    I'm happy to give it a try when I have some time, but I have 0 problems with git right now so it's not top of my list. My critique is also really not towards jj specifically, I'm just discussing the idea that git has extremely wide adoption now and that this has benefits :)

miki123211 1y ago

It's important that jj (the local VCS) is fully compatible with Git (the protocol / interoperability standard). I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.

CGamesPlay 1y ago

I started using git when my employer still used svn. This was possible because `git-svn` was so good and it seamlessly allowed me to use branches to do development while still committing to svn's trunk. I think jj is trying to do something similar: jj-unaware tools work reasonably well in colocated jj repositories, and jj-unaware peers (CI tools, etc) work exactly as they did before. I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.

mpalmer 1y ago

More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Not true. Using jj is a choice made by a single developer. Nothing proprietary escapes from a jj clone of a git repo. Junior devs can use vanilla git if they really want to. All the tooling that works with e.g. repo analysis will need to start supporting git and jj Also not true, unless I misunderstand what you mean by repo analysis. Colocated jj repos are more or less supersets of git repos.

jtwaleson 1y ago
I see what you mean, and having looked a bit more deeply today, it's clear that jj is very compatible. However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Windows and Linux (Debian, Arch, Ubuntu, etc). Teams do it, and it's all possible, but it was nice that at least everyone used git.
- deleted 1y ago
  [deleted]
- mpalmer 1y ago
  If a team has members who unilaterally rewrite best practice docs to include their preferred technologies, the fault is not with the tech.
  - jtwaleson 1y ago
    I didn't pick a great example and didn't explain it eloquently, but I hope you understand my point. Supporting multiple ways of working takes effort.

CuriouslyC 1y ago

Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch. The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.

mpalmer 1y ago
I have no idea what problem this is supposed to solve. Where is the V in VCS here? How do you track the provenance/history of changes? You may not be "forcing" developers to "screw with a graph" (what?) but you are forcing them to screw with macros (we're adding a built-in scripting layer to the VCS?) and these unfamiliar new concepts called atoms and plans. > A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans) And it would introduce zero new confusing issues of its own? > This would also [...] make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch. This is a weird use case. Version control systems aren't typically used for storing and swapping around bits of functionality as a first-class, ongoing concern. Not to mention you still need to figure out how atoms get stitched together. How do you do it without diff-based patches? No superior solution exists, AFAIK. tl;dr use workspaces if you're using agents.
- CuriouslyC 1y ago