Pijul: patch-based like Darcs but apparently solves its performance issues. In theory this improves conflict resolution.
Jujutsu: kind of an alternative front-end to a git repo (but not a front-end to git). Has some different ideas, like no staging area (draft commit), and some other stuff I can’t remember.
Sapling: from Facebook. Unfortunately only part of it is available. The server is not public yet (I guess it’s tired up in Facebook infrastructure too much).
And it’s definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:
Monorepo support is relatively poor, especially on Mac and Linux.
Submodule support is extremely buggy and has particularly bad UX even for Git.
Support for large files via LFS is tacked on and half-arsed.
Conflict resolution is very very dumb. I think there are third party efforts to improve this.
I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.
Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.
It’s not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it’s a tacked on third party solution which doesn’t integrate well, like LFS.)
Aside from the obvious UX disaster, Git has some big issues:
I find this blend of claims amusing. I’ve been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called “disasters”. Odd.
What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn’t, but I would not call any of these “disasters”. The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn’t have been bundled. It’s nothing an interactive rebase doesn’t solve, but it’s multiple steps that could be one.
Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.
I don’t see why using submodules as a package manager should excuse their endless bugs.
I don’t know what are these “endless bugs” you’re talking about. Submodules might have a UX that’s rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.
Do you actually have any specific, tangible issue with submodules? Even in the cases you’re clearly and grossly misusing them
I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimizations and bare minimum partial checkout support.
Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.
The partial checkout support in Git is getting improved. Take a look, maybe it now solves your problems.
Support for large repositories via scalar works also for Linux (though not everything is ported; as main body of work on supporting large repositories was created to deal with the size of MS Windows repository, it started with Windows-only support / optimization first).
And it’s definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:
I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.
Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.
It’s not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it’s a tacked on third party solution which doesn’t integrate well, like LFS.)
I find this blend of claims amusing. I’ve been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called “disasters”. Odd.
What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn’t, but I would not call any of these “disasters”. The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn’t have been bundled. It’s nothing an interactive rebase doesn’t solve, but it’s multiple steps that could be one.
Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.
I don’t see why using submodules as a package manager should excuse their endless bugs. I think you just have low standards.
The UX flaws of Git are very obvious IMO. Even the naming is terrible (“index”? What was wrong with “draft”?).
I don’t know what are these “endless bugs” you’re talking about. Submodules might have a UX that’s rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.
Do you actually have any specific, tangible issue with submodules? Even in the cases you’re clearly and grossly misusing them
The partial checkout support in Git is getting improved. Take a look, maybe it now solves your problems.
Support for large repositories via
scalarworks also for Linux (though not everything is ported; as main body of work on supporting large repositories was created to deal with the size of MS Windows repository, it started with Windows-only support / optimization first).There are alternatives to submodules, like https://github.com/chronoxor/gil