7 ms·

I think it's a tall order for another SCM to challenge git. I can't imagine how it could be any more entrenched in the industry. Further, I'm happy with git. I

I think it's a tall order for another SCM to challenge git. I can't imagine how it could be any more entrenched in the industry. Further, I'm happy with git. I played with Mercurial years ago, long enough to work with it day-to-day, and just didn't find any relevant advantages versus git. I love that people are still out there trying to improve things, and certainly don't want that to stop, but it's difficult for me to imagine switching at this point.

shashashasha___ 5y ago
it solves scale issues that git can't solve at the moment. fb monorepos are huge. so for most people/companies this issue is not critical to solve and git is great.
qbasic_forever 5y ago
I don't think it's trying to compete with git, it's not decentralized or meant to support big distributed open source project development. This looks like a nice tool for Big Company to manage its internal, private code repositories.
- z3t4 5y ago
  The decentralized part of Git and Mercurial is nice (eg. no need for Github et.al), but I think most software projects using Git or Mercurial do have a centralized server/hub...
avgcorrection 5y ago
This looks like it’s supposed to be more appropriate for very, very big repos. Which current Git doesn’t support and isn’t fundamentally designed to support. So rather than use Git + Git Annex or something like that (maybe more), you’ll just use this alternative SCM. (I keep hearing about how Git will eventually support big repos, but it’s still not on the horizon. Big repos with Git still seems to be limited to big corps who have the resources to make something bespoke. Personally I don’t use big repos so I have no skin in this game.)
- kevincox 5y ago
  Big repos work in Git today if you are able to play the sparse checkout dance. There are definitely more improvements to be made. - Protocol for more efficiently widening sparse checkouts. - Virtual filesystem or other solution for automatically widening sparse checkouts to greatly improve the UX. - Ideally changing sparse checkouts from a repo state to just some form of lazy loading. Otherwise as you touch more files your performance will slowly degrade.
ithkuil 5y ago
A SCM like https://pijul.org/ https://pijul.org/ would be a challenge to git. Eden is more a challenge for things like perforce.
- dan-robertson 5y ago
  Yeah I think the directions are quite different. Both are improving user experience (either commands/behaviour with pijul or speed with Eden) but pijul is distributed with some efforts to improve algorithms but a bigger focus on improving semantics (making it more natural in some sense and more correct in another) whereas Eden is more centralising (the thing large companies want for their repo is branching not decentralisation, but DVCSes give the former mostly via the latter (I get that branches are a first class thing in git but much of their technical implementation can follow from things git must have to be distributed)) with a focus on massive size. One thing I recall was an effort from pijul to make blaming a file run in O(n log h) where n is the size of the file and h is the size of the (repo or file, I’m not sure) history. I wonder if Eden will also have improved blame performance. I noticed they mentioned large histories but maybe it is still linear in the history size of the file. (The way hg works gives I think O(nh) where h is the size of the file history, which he stores per-file rather than per-commit like git).
cproctor 5y ago
OK, slightly off-topic but maybe the right minds are here. We have been developing an introductory CS curriculum committed to thinking-with-powerful-tools, including the command line, real programming languages, and git. It's great until it isn't. We intentionally maintain a simplified workflow, but still get the occasional merge conflict or local state blocking a pull. I keep thinking there must be a simplified wrapper over git which maintains the conceptual power while avoiding the sharp edges, even if at the cost of robustness. I'd be more interested in an abstraction than a GUI, but would be interested to hear whatever others have come up with.
- avar 5y ago
  Can you show a step by step list of git commands where you find the interface to be bad?
- dan-robertson 5y ago
  The git user interface just sucks. hg supposedly has a better UI, and darcs is apparently better again (except sometimes merges could run in exponential time). Pijul is meant to give you darcs-like ui with good performance. But none of those things are fit which is maybe important to teach. One possibility could be to use some kind of git ui. I only know about magit (which is built on/in Emacs) but I’m sure others exist.
- galaxyLogic 5y ago
  How about git-compatible https://github.com/martinvonz/jj https://github.com/martinvonz/jj ?
- RichieMartin 5y ago
  Have you checked out Sturdy? It's a git-compatible VCS, with a much simplified UI and workflow. https://getsturdy.com/ https://getsturdy.com/
mountainriver 5y ago
I would just love it if git could handle large files, it causes a lot of hacky solutions right now
jchw 5y ago
If you go to work for Google or Facebook, it quickly becomes apparent that switching SCMs is much cheaper than trying to use ordinary Git or Mercurial at scale. (Though it is clear that Google, Facebook and Microsoft are all trying to maximize the amount of familiarity and not reinvent the wheel too much; they all have been working on tools either building on, utilizing, or based on already existing SCM tools.)
efsavage 5y ago
The biggest differentiation for me between Git and Mercurial is that Mercurial is far better for code reviews because it manages stacks of "as small as possible" changes much easier. The git workarounds I've tried to replicate 'hg histedit' and 'hg absorb' are ... not good. Similarly, I think Git(hub) has succeeded in open source because bundling more complete changes into PRs works well for unevenly distributed contributions.
m12k 5y ago
I'm also happy with git, but there's 3 main things that could improve on git IMO: 1) Better handling of large files than git-lfs. As in 10+ GB repos. This is needed for game development (currently they tend to use Perforce or PlasticSCM) 2) Sparse checkout via file system integration (like Eden has) 3) Build system integration, so unchanged files and modules don't even need to be fetched to be compiled, because cached builds can be fetched from a build server instead (requires proper modularization, so e.g. C++ macro expansion doesn't just prevent anything from being cacheable) These are all features that primarily have value for repos that push the limits on size, like big monorepos (with a huge amount of files) or game development (with big asset files). But get it right, and you could massively cut down the time it takes to check out a branch and build it.
- webmaven 5y ago
  > These are all features that primarily have value for repos that push the limits on size, like big monorepos (with a huge amount of files) or game development (with big asset files). But get it right, and you could massively cut down the time it takes to check out a branch and build it. Would this be a good fit for large machine learning data sets? Every time a new model comes out that touts having been trained on something like a quarter of a billion images, I ask myself "how the heck does someone manage and version a pile like that?"
  - zem 5y ago
    would you ever need to version individual images? at a high level, you could version the collection as a whole by filtering by timestamp, and moving deleted files to a "deleted" directory, or maintaining filename and timestamps in a database. I'm sure there are lots of corner cases that would come up when you actually tried to build such a system, but I don't think the overall scheme needs to be as conceptually complex as source code version control
    - webmaven 5y ago
      > would you ever need to version individual images? Potentially. It would depend on the image format and what metadata is (or can be) included in the file.
markstos 5y ago
Coming from Darcs, Git has a horrible user interface. Something like Jujutsu has a chance to disrupt Git. It can use the Git data store, so developers can in theory start using it without the whole team adopting it. Then it addresses the big problem with Git, the user interface: https://github.com/martinvonz/jj https://github.com/martinvonz/jj I'm not suggesting that "jj" in particular will disrupt Git, but I think eventually the a tool which supports the git data store with a better user interface could take hold.
- tick_tock_tick 5y ago
  Git usage for most developer is 3-4 commands or once in a blue moon when they fuck up badly save a copy of your changes and reset hard. There aren't enough user interface improvements possible to get people to switch.
optymizer 5y ago
I used Meta's Mercurial, having previously used primarily git (and SVN, and CVS before that). It has a number of very cool improvements over git, and it's well integrated into the rest of their infrastructure. You know the feeling of having to use SVN after using Git? This is what it feels like to use Git after getting used to Meta's Mercurial. I wish I could go into the details, but I don't know how much of it was ported back to Mercurial.
noobermin 5y ago
I don't think them putting it out is an attempt to compete with anything, they're just putting it out to put it out. If they are then I totally agree.
cachvico 5y ago
Actually Git isn't quite so entrenched as you think. Perforce is still the norm in the games industry, for example, partly because it's more artist-friendly.
RichieMartin 5y ago
I've been keeping an eye on Sturdy [1], a more performant, high level, and opinionated version control system. As a bonus, it seems to be compatible with Git. 1: https://github.com/sturdy-dev/sturdy https://github.com/sturdy-dev/sturdy
kevincox 5y ago
The biggest problem I have with Git is the strong commit ordering. This leads to lack of tracking through cherry-picks which has very real friction for a fairly common workflow.

shashashasha___ 5y ago

it solves scale issues that git can't solve at the moment. fb monorepos are huge. so for most people/companies this issue is not critical to solve and git is great.

qbasic_forever 5y ago

I don't think it's trying to compete with git, it's not decentralized or meant to support big distributed open source project development. This looks like a nice tool for Big Company to manage its internal, private code repositories.

z3t4 5y ago
The decentralized part of Git and Mercurial is nice (eg. no need for Github et.al), but I think most software projects using Git or Mercurial do have a centralized server/hub...

avgcorrection 5y ago

This looks like it’s supposed to be more appropriate for very, very big repos. Which current Git doesn’t support and isn’t fundamentally designed to support. So rather than use Git + Git Annex or something like that (maybe more), you’ll just use this alternative SCM. (I keep hearing about how Git will eventually support big repos, but it’s still not on the horizon. Big repos with Git still seems to be limited to big corps who have the resources to make something bespoke. Personally I don’t use big repos so I have no skin in this game.)

kevincox 5y ago
Big repos work in Git today if you are able to play the sparse checkout dance. There are definitely more improvements to be made. - Protocol for more efficiently widening sparse checkouts. - Virtual filesystem or other solution for automatically widening sparse checkouts to greatly improve the UX. - Ideally changing sparse checkouts from a repo state to just some form of lazy loading. Otherwise as you touch more files your performance will slowly degrade.

ithkuil 5y ago

A SCM like https://pijul.org/ https://pijul.org/ would be a challenge to git. Eden is more a challenge for things like perforce.

dan-robertson 5y ago
Yeah I think the directions are quite different. Both are improving user experience (either commands/behaviour with pijul or speed with Eden) but pijul is distributed with some efforts to improve algorithms but a bigger focus on improving semantics (making it more natural in some sense and more correct in another) whereas Eden is more centralising (the thing large companies want for their repo is branching not decentralisation, but DVCSes give the former mostly via the latter (I get that branches are a first class thing in git but much of their technical implementation can follow from things git must have to be distributed)) with a focus on massive size. One thing I recall was an effort from pijul to make blaming a file run in O(n log h) where n is the size of the file and h is the size of the (repo or file, I’m not sure) history. I wonder if Eden will also have improved blame performance. I noticed they mentioned large histories but maybe it is still linear in the history size of the file. (The way hg works gives I think O(nh) where h is the size of the file history, which he stores per-file rather than per-commit like git).

cproctor 5y ago

OK, slightly off-topic but maybe the right minds are here. We have been developing an introductory CS curriculum committed to thinking-with-powerful-tools, including the command line, real programming languages, and git. It's great until it isn't. We intentionally maintain a simplified workflow, but still get the occasional merge conflict or local state blocking a pull. I keep thinking there must be a simplified wrapper over git which maintains the conceptual power while avoiding the sharp edges, even if at the cost of robustness. I'd be more interested in an abstraction than a GUI, but would be interested to hear whatever others have come up with.

avar 5y ago
Can you show a step by step list of git commands where you find the interface to be bad?
dan-robertson 5y ago
The git user interface just sucks. hg supposedly has a better UI, and darcs is apparently better again (except sometimes merges could run in exponential time). Pijul is meant to give you darcs-like ui with good performance. But none of those things are fit which is maybe important to teach. One possibility could be to use some kind of git ui. I only know about magit (which is built on/in Emacs) but I’m sure others exist.
galaxyLogic 5y ago
How about git-compatible https://github.com/martinvonz/jj https://github.com/martinvonz/jj ?
RichieMartin 5y ago
Have you checked out Sturdy? It's a git-compatible VCS, with a much simplified UI and workflow. https://getsturdy.com/ https://getsturdy.com/

mountainriver 5y ago

I would just love it if git could handle large files, it causes a lot of hacky solutions right now

jchw 5y ago

If you go to work for Google or Facebook, it quickly becomes apparent that switching SCMs is much cheaper than trying to use ordinary Git or Mercurial at scale. (Though it is clear that Google, Facebook and Microsoft are all trying to maximize the amount of familiarity and not reinvent the wheel too much; they all have been working on tools either building on, utilizing, or based on already existing SCM tools.)

efsavage 5y ago

The biggest differentiation for me between Git and Mercurial is that Mercurial is far better for code reviews because it manages stacks of "as small as possible" changes much easier. The git workarounds I've tried to replicate 'hg histedit' and 'hg absorb' are ... not good. Similarly, I think Git(hub) has succeeded in open source because bundling more complete changes into PRs works well for unevenly distributed contributions.

m12k 5y ago

I'm also happy with git, but there's 3 main things that could improve on git IMO: 1) Better handling of large files than git-lfs. As in 10+ GB repos. This is needed for game development (currently they tend to use Perforce or PlasticSCM) 2) Sparse checkout via file system integration (like Eden has) 3) Build system integration, so unchanged files and modules don't even need to be fetched to be compiled, because cached builds can be fetched from a build server instead (requires proper modularization, so e.g. C++ macro expansion doesn't just prevent anything from being cacheable) These are all features that primarily have value for repos that push the limits on size, like big monorepos (with a huge amount of files) or game development (with big asset files). But get it right, and you could massively cut down the time it takes to check out a branch and build it.

webmaven 5y ago
> These are all features that primarily have value for repos that push the limits on size, like big monorepos (with a huge amount of files) or game development (with big asset files). But get it right, and you could massively cut down the time it takes to check out a branch and build it. Would this be a good fit for large machine learning data sets? Every time a new model comes out that touts having been trained on something like a quarter of a billion images, I ask myself "how the heck does someone manage and version a pile like that?"
- zem 5y ago
  would you ever need to version individual images? at a high level, you could version the collection as a whole by filtering by timestamp, and moving deleted files to a "deleted" directory, or maintaining filename and timestamps in a database. I'm sure there are lots of corner cases that would come up when you actually tried to build such a system, but I don't think the overall scheme needs to be as conceptually complex as source code version control
  - webmaven 5y ago
    > would you ever need to version individual images? Potentially. It would depend on the image format and what metadata is (or can be) included in the file.

markstos 5y ago

Coming from Darcs, Git has a horrible user interface. Something like Jujutsu has a chance to disrupt Git. It can use the Git data store, so developers can in theory start using it without the whole team adopting it. Then it addresses the big problem with Git, the user interface: https://github.com/martinvonz/jj https://github.com/martinvonz/jj I'm not suggesting that "jj" in particular will disrupt Git, but I think eventually the a tool which supports the git data store with a better user interface could take hold.

tick_tock_tick 5y ago
Git usage for most developer is 3-4 commands or once in a blue moon when they fuck up badly save a copy of your changes and reset hard. There aren't enough user interface improvements possible to get people to switch.

optymizer 5y ago

I used Meta's Mercurial, having previously used primarily git (and SVN, and CVS before that). It has a number of very cool improvements over git, and it's well integrated into the rest of their infrastructure. You know the feeling of having to use SVN after using Git? This is what it feels like to use Git after getting used to Meta's Mercurial. I wish I could go into the details, but I don't know how much of it was ported back to Mercurial.

noobermin 5y ago

I don't think them putting it out is an attempt to compete with anything, they're just putting it out to put it out. If they are then I totally agree.

cachvico 5y ago

Actually Git isn't quite so entrenched as you think. Perforce is still the norm in the games industry, for example, partly because it's more artist-friendly.

RichieMartin 5y ago

I've been keeping an eye on Sturdy [1], a more performant, high level, and opinionated version control system. As a bonus, it seems to be compatible with Git. 1: https://github.com/sturdy-dev/sturdy https://github.com/sturdy-dev/sturdy

kevincox 5y ago

The biggest problem I have with Git is the strong commit ordering. This leads to lack of tracking through cherry-picks which has very real friction for a fairly common workflow.