Command name conflicts with the `sl` utility that has existed for decades. https://github.com/mtoyoda/sl
"It's just a joke command, and not useful at all." with the last release 8 years ago. I understand that Meta didn't mind conflicting with that.
Sapling: A new source control system with Git-compatible client
71–80 of 543 posts
Re: Sapling: A new source control system with Git-compatible client
#72Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it…
It's worth pointing out: React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world. Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line. [0] https://github.com/facebook/react
Don't forget projects like PyTorch, Presto, etc.
Re: Sapling: A new source control system with Git-compatible client
#73Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it…
If you think Facebook are bad when it comes to abandoning software projects, try Microsoft.
Re: Sapling: A new source control system with Git-compatible client
#74Earlier quoted context omitted.
In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not having them, but Git would have been better off if they consolidated into a single idea and concentrated their efforts on that. If you can remove a concept from Git and still suppor…
Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-…
We know empirically that the staging area is a major pain point for users in practice, as discussed in https://investigating-archiving-git.gitlab.io/
The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research
Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles this the same way it handles splitting commits in general. Essentially, it has a greater set of verbs that act on a smaller set of nouns, where Git has a medium set of verbs that act on a medium set of nouns.
Re: Sapling: A new source control system with Git-compatible client
#75Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it…
Interesting. FB also open-sourced Thrift and then promptly had fbthrift diverge instantly.
Overall, I'm glad they do these things, though since it is better to have this code accessible than absent. Good on them!
Re: Sapling: A new source control system with Git-compatible client
#76> There is no staging area. I don't actually want "No" staging area. What I want is, once I "add" something, the file stays added. Currently, I have `git st` alias setup : st = !git add -u && git status This auto-updates the staging area for files that were previously staged. So I get `git add` but also don't have to re-add anything manually from there ... Since I do `git st` quite frequently, this works out for me .…
This would break the workflow of using the staging area to break a larger change into smaller commits. git add -p Allows you to select hunks of changes and stage them for committing...
For GP's use case, its "added some stuff, want to stage the stuff I modified since then to those files"... which I feel is a perfectly normal workflow.
There's nothing saying that one can't add chunks to the staging area and then immediately commit it without invoking that alias afterwards (since it is a very deliberate "add these things" rather than "adding a bunch of things and keep adding."
Re: Sapling: A new source control system with Git-compatible client
#77The interactive tool looks amazing. I do interactive rebases quite often and a drag-drop setup is wonderful However, I don't understand why I would want 1 PR per commit. I feel like that's a non-starter for me. Is the idea that no one should use branches - so there's only 3 points of interest: HEAD, main, and origin/main? And then is the idea that it's only 1 commit per feature to merge? So I would work on something,…
Generally, you "stack" your commits/PRs and review them in small units (which I think is what you mean by working on something else without making any Git checkouts).
But you can certainly create new "branches" of development which aren't stacked on top of each other. They just don't have to have names. You can consider them to be "anonymous" branches.
The main advantage of 1 commit per PR is to review and commit smaller changes (a single commit at a time).
Re: Sapling: A new source control system with Git-compatible client
#78Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it…
The nice thing is that this is a client that works with vanilla git servers - if you switch to using it now, best case, you get a lifetime of good ergonomics; worst case, you get a few months of good ergonomics before something breaks that upstream doesn’t want to fix, and you go back to using the vanilla git client.
Re: Sapling: A new source control system with Git-compatible client
#79Earlier quoted context omitted.
It's worth pointing out: React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world. Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line. [0] https://github.com/facebook/react
Don't forget projects like PyTorch, Presto, etc.
Oh, right! I forgot PyTorch was originally Facebook (and it's not under their umbrella anymore).
Re: Sapling: A new source control system with Git-compatible client
#80Earlier quoted context omitted.
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 t…
Fortunately, zstd seems to be in active development: https://github.com/facebook/zstd 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 probably a naive take, but I think of compression software as something that can be “done”. Unlikely to be a lot of code churn required for such a project to be relevant for a very long time.