Ah, there it is. I was wondering when this would happen.
Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.
Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb
Absorb is fantastic and one of Jun Wu's (seen in this thread as quark12) best contributions to Mercurial. I want everyone to know about this tool, it's amazing. I had fun trying to come up with a name for the feature:
It seems this is still based on changing history - Does hg have something to address the downsides of rebasing that are present in git? such as chilling effect on cooperation of branches (eg you don't dare touch or use remote branches which someone may use rebase on, and destruction of actual history for use in eg reconstructing a timeline of a bug and fix later found to be important).
Slight correction: HipHop for PHP was cleanroom, including rewriting large families of native extensions to work with its C++ runtime, although it eventually developed workalikes for the PHP dev headers to ease development. Source: I worked on HHVM, its JIT successor that initially shared its source tree and runtime.
Facebook developers seem to have a surprising amount of free time to go around reinventing things that are not obviously social network features. (Or to have had it in the 2010s, at least.)
I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to.
Yes, I read the manual for git, but I never needed to for Mercurial.
I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .
What are the changes that Mercurial has? I've read many times that Mercurial is easier but I've never seen the reasons. The times I've used mercurial (mostly to download a repo) it doesn't look that different, and other than the staging area weirdness I don't find git too difficult.
The way Mercurial is structured is, to me, intuitive, easy, and powerful. I'm still using it for all of my local projects; luckily hg-git lets you pull in dependencies from github, which would otherwise require me to switch to git.
As someone who used to be intimately involved in the development of PHP, HHVM was an interesting project because for a long time it supported standard PHP (alongside Facebook's custom language, Hack), so it brought competition to the implementation space! But eventually Facebook lost interest in that part, probably because they had no use for it.
If Sapling encourages a Git-usability renaissance the same way HHVM encouraged PHP to get good performance and typing, even if it eventually gets abandoned, I will be thankful for it :)
Mercurial has a far better user experience and mental model. The commonly used commands simply do what their names say: hd add, hg commit, hg revert, hg update, and so on.
Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.
I was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.
> I really hope that git is not the final word in version control.
common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.
deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.
same reason why it's hard to make a Facebook alternative.
That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that.
Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you.
People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.
This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.
The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
Because that's how progress slowly happens? If I have an issue with something, and come up with a possible solution, and then ask why it's not actually done like that... Either other people tell me I'm wrong and explain why, or they agree and things get better.
> and there are still those of us who actually use Mercurial
I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
Yeah, we should give a shout-out to the octobus folks for making heptapod, a Gitlab fork bringing support for mercurial repos. That brings at least one mainstream hosting option for hg repos.
I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02...) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it.
This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.
My brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard <commit>", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh.
Well in that situation you can stash unstaged, reset, then pop. But that just reinforces the OP’s point. Not the most ergonomic or discoverable path for something that should be simple to do.
git reset HEAD@{1} should do the trick to "uncommit" and keep uncommitted changes in the absence of conflicts. (I may be missing some edge cases.) It does however unstage changes.
I don't blame git, I'm mostly surprised about the social inertia regarding improving it. But like programming languages, pressure accumulate until it's released, I'm sure sapling and similar will make people want to try new things and git will soon catch up.
The social inertia point is an interesting one. It seems like in some areas, like JavaScript frameworks, there is a ton of inertia for change; in other areas, like git, there is a ton of inertia for stasis. Why is that?
Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen.
Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.
because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach
dude, vscode git interface is ... not really good.
I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo
Admittedly this might not help since it is not CLI, but spend some time this weekend with Emacs and magit. You don't have to use emacs for anything else, just the magit client. It will transform your git experience.
I did something similar for years with Sublime and Gitsavvy. But I couldn't stop Sublime updating itself from time to time, and it kept breaking Gitsavvy, and it got really tedious to try to fix it.
I got 90% of the way there with a lot of git aliases. The other 10% is constraining your workflow and reasoning about what state each of your commands leaves the git tree in.
git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.
Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions.
Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases (like me). But I'm still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.
Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them.
...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence that I've run into more abandonware from FB than Google?
Better than Microsoft? I don't think I've ever been able to talk to a human at Google, whereas with Microsoft, I get feedback very quickly on issues and pull requests. Does Google even interact with people with open source? For example, I am using Skia via SkiaSharp, and the only place I know of to go for Skia help and issues is their Google Groups page, a website out of the 2000s. And very few seem to actually monitor the group. I'm not even really sure what Google does in open source. Even the things that are released to the public, like Skia, are well known to come with a huge amount of internal baggage.
Whereas Microsoft has dozens of active projects on GitHub where you can talk directly with the people working on it at Microsoft.
As far as I can tell, most of zstd's development is still by Facebook employees, though not all of it. I tend to think zstd has enough traction that development would continue even if FB were to abandon the project.
How to not abondon a project? I would love to know that.
This is my naive understanding. A for profit company open sources a project that they have been using and developing internally. The have built a philosophy and understanding of the project as they use and develop it. Most of their action regarding the project is that they must use it and they usually don't have any other options.
Because the foundation is already laid the solution for its shortcoming is having just an understanding of them. Then you open source the project knowing that you have developed the project to it's completion.
Now comes the OSS community. Either we request features that goes against the project philosophy or we don't want to get involved because we don't need to compromise and acknowledge the shortcomings because we have options.
A good solution can be open sourcing projects that the org thinks isn't complete and needs further development without compromising security, philosophy and usability. Because if you have a list of things you need, you can ask the OSS community to fix those things rather then be critical of the foundation and philosophy.
Good points. Personally, a lot of the appeal of open source is not so much about having free stuff, it's more about being able to learn from others. I learned a ton from the various engines Id Software released back in the day, but have no expectation that they maintain them.
If it comes to stuff I actually want to _use_, I avoid projects backed by a single or a few companies - like Sapling. So from that angle, I'm not particularly impressed either.
React Native, named after their open source project that is incredibly successful, widely used, completely reshaped the front end dev world, etc... Not sure if an offshoot of a world class project not gaining traction is a mark against them.
There recently was a thread here on the impact of layoffs on React. And apparently even Facebook has abandoned react for anything but internal projects.
Tbf I think this was just the learning curve for big tech companies. Google and Facebook face scalability problems other companies 5 years before anyone else so if they don't open source the solutions they come up with, the industry-standard that establishes itself 5 years later will not be compatible with their solution and they will have a hard time recruiting and keeping personnel for their own system.
In the argument of monorepo vs not, the usual argument goes like this:
- It's too hard to scale for a large monorepo!
- Google does it just fine!
- But I don't have access to Google's tools!
So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.
Microsoft uses monorepos, and you have access to Microsoft's tools! They chose to work with Git and amend it when necessary, just like Meta did with Mercurial.
A few years ago they had a Virtual File System extension for Git. Now it's a public fork of Git that is intended for large repositories (several hundreds of GB). It adds a `git scalar` command, see https://github.com/microsoft/git/blob/HEAD/contrib/scalar/do...
Mostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of git and/or have giant amounts of binaries in their repos. Actually having Gigabytes of source code is pretty rare.
> and/or have giant amounts of binaries in their repos.
Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems.
Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"
It depends on the size of the company. The Linux kernel has about 1500 active developers. This is a lot, but many companies also exist that reach this size.
I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.
I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and making commits as I go along doesn't work well.
How does sapling let me take a long list of commits and break them into larger but more manageable chunks?
git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits.
Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the "whole" vs a patch that is more localized.
Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning).
To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).
If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke.
It sounds like I would need to:
- switch
- amend the commit
- restack?
- switch back to the HEAD?
https://sapling-scm.com/docs/introduction/differences-git#sa... says:
"If you want to commit/amend just part of your changes you can use commit/amend -i to interactively choose which changes to commit/amend. Alternatively, you can simulate a staging area by making a temporary commit and amending to it as if it was the staging area, then use fold to collapse it into the real commit."
To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless. Then, you can use your usual staging workflows if desired, or use regular Git commands directly.
Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?
Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.
> To use a similar featureset but in the same Git repository you normally use
What do you mean? Can't you use Sapling in the same Git repository you normally use? The first sentence is "Sapling is a new Git-compatible source control client". Is there something they're not telling us?
EDIT: Looks like it calls out to the git executable occasionally (https://news.ycombinator.com/item?id=33615576) and presumably works on the git object model under the hood, but you can't use `git` on a repo checked out using `sl` nor vice versa. It's a stretch to call it Git-compatible but I guess not completely wrong.
What I mean is that you can't co-locate your Sapling repository with your Git repository (at least, for now). You have to have them in separate directories and push/pull between them.
git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)
> Looks like it calls out to the git executable occasionally
I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.
> presumably works on the git object model under the hood
There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.
I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy.
Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4).
No, the CLI prevents that because the remote is unlikely to know how to interpret conflicts. In a future where the remote understands conflicts, then you'll be able to push conflicts to a remote and collaborate on the conflict resolution.
I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.
I’ve been using FB’s mercurial fork for years, wishing for all that time that I could have the joy of the fb-hg CLI while remaining compatible with github because that’s where 99+% of the code lives - from my brief experimentation, sapling appears to be that. I look forward to never using the git CLI again :D
I actually just created my first PR from a sapling repo now - not sure why it’s not documented, but you can push your local development branch to a remote server, and in the case of github, you even get the “it looks like you’ve just pushed a local branch, would you like to turn this branch into a PR?” prompt, and it appears indistinguishable from a branch created with the Git CLI.
Reading the documentation quickly, it looks like you can generate a standard pull request, it's just that the PR may not conform to expectations if there are multiple commits.
Of course, when it comes to github PRs, there are so many different "styles" of pull request, I'm not even sure which one should be considered "standard".
Readit News
Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.
For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling.
Overall this looks promising.
[1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...
Hard to discover and remember but once you do it usually works smoothly.
https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur...
Yes, I read the manual for git, but I never needed to for Mercurial.
I wish it had won the DVCS wars.
Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.
> The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.
https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.
deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.
same reason why it's hard to make a Facebook alternative.
Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...
Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you.
People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.
This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.
The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
Deleted Comment
Deleted Comment
Could you elaborate on what these things are and why you disagree with them?
I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02...) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it.
This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.
So yes, in short I agree.
Put my stuff from the last commit back into working directory?
Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.
https://github.com/martinvonz/jj
[0]: https://github.com/jesseduffield/lazygit
[0]: https://www.youtube.com/watch?v=CPLdltN7wgE
just they build one for switch.
i hope they build a migrate one, where you can switch to new/other hashing standards.
(Disclaimer used to make VSCode)
Harder with an amend due to having to get the difference of commits within the reflog, sure.
Deleted Comment
Dead Comment
Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases (like me). But I'm still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.
...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence that I've run into more abandonware from FB than Google?
Better than Microsoft? I don't think I've ever been able to talk to a human at Google, whereas with Microsoft, I get feedback very quickly on issues and pull requests. Does Google even interact with people with open source? For example, I am using Skia via SkiaSharp, and the only place I know of to go for Skia help and issues is their Google Groups page, a website out of the 2000s. And very few seem to actually monitor the group. I'm not even really sure what Google does in open source. Even the things that are released to the public, like Skia, are well known to come with a huge amount of internal baggage.
Whereas Microsoft has dozens of active projects on GitHub where you can talk directly with the people working on it at Microsoft.
As far as I can tell, most of zstd's development is still by Facebook employees, though not all of it. I tend to think zstd has enough traction that development would continue even if FB were to abandon the project.
This is my naive understanding. A for profit company open sources a project that they have been using and developing internally. The have built a philosophy and understanding of the project as they use and develop it. Most of their action regarding the project is that they must use it and they usually don't have any other options.
Because the foundation is already laid the solution for its shortcoming is having just an understanding of them. Then you open source the project knowing that you have developed the project to it's completion.
Now comes the OSS community. Either we request features that goes against the project philosophy or we don't want to get involved because we don't need to compromise and acknowledge the shortcomings because we have options.
A good solution can be open sourcing projects that the org thinks isn't complete and needs further development without compromising security, philosophy and usability. Because if you have a list of things you need, you can ask the OSS community to fix those things rather then be critical of the foundation and philosophy.
Whatever is cool at Google IO XYWX is already abandoned by the time we reach into Google IO XYWX + 1.
[1] https://killedbygoogle.com/
If it comes to stuff I actually want to _use_, I avoid projects backed by a single or a few companies - like Sapling. So from that angle, I'm not particularly impressed either.
- It's too hard to scale for a large monorepo!
- Google does it just fine!
- But I don't have access to Google's tools!
So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.
A few years ago they had a Virtual File System extension for Git. Now it's a public fork of Git that is intended for large repositories (several hundreds of GB). It adds a `git scalar` command, see https://github.com/microsoft/git/blob/HEAD/contrib/scalar/do...
Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems.
Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"
I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.
How does sapling let me take a long list of commits and break them into larger but more manageable chunks?
git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits.
Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the "whole" vs a patch that is more localized.
To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).
It sounds like I would need to:
- switch - amend the commit - restack? - switch back to the HEAD?
Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sapling-scm.com/docs/commands/fold
This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.
your workflow resembles mine so I'm in the obligation of mentioning https://github.com/jesseduffield/lazygit which allows you to stage individual lines among other features. https://www.youtube.com/watch?v=CPLdltN7wgE
Sure, but you can use `git commit -p` to get the same benefits without explicitly using the staging area.
I also use this workflow. Lots of detached HEAD mode, using the index to commit things piecemeal, then rebase as needed, until I'm finally done.
Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?
Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.
What do you mean? Can't you use Sapling in the same Git repository you normally use? The first sentence is "Sapling is a new Git-compatible source control client". Is there something they're not telling us?
EDIT: Looks like it calls out to the git executable occasionally (https://news.ycombinator.com/item?id=33615576) and presumably works on the git object model under the hood, but you can't use `git` on a repo checked out using `sl` nor vice versa. It's a stretch to call it Git-compatible but I guess not completely wrong.
EDIT2: Here's a good summary https://news.ycombinator.com/item?id=33617689
git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)
> Looks like it calls out to the git executable occasionally
I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.
> presumably works on the git object model under the hood
There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.
Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4).
Is this pushed to the remote when running as a git porcelain?
https://www.mercurial-scm.org/repo/hg/graph/tip
, seems to have been included since 2005 :)
Yes, this would be awesome for Mercurial.
...until I got to pull requests (Granted, that is github, not git). But it looks like you cannot generate a standard pull request with it.
https://sapling-scm.com/docs/git/intro#pull-requests
Haven’t tried it yet, looking forward to it.
Of course, when it comes to github PRs, there are so many different "styles" of pull request, I'm not even sure which one should be considered "standard".
GP was probably talking about a time when they used it internally but maybe it didn't have a name by then.