Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sapling: A new source control system with Git-compatible client

engineering.fb.com

Post reply on HN
Print view View original

101–110 of 543 posts

Re: Sapling: A new source control system with Git-compatible client

#101

Post by durham_meta »

thijser wrote: post #90
durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

I'm curious about the tech stack. It seems to be a combination of Rust and Python? How does that exactly work?

Sapling originated from the Mercurial open source project, which was largely Python (at the time). To make things faster and more maintainable, we started rewriting portions of it in Rust, and going through a binding layer to interact with Python. Critical pieces like the storage layer, parts of the wire protocol, and various others are all in Rust at this point, while a lot of the high level business logic remains in Python. We'll continue to shift more to Rust over time though, especially since pure-Rust Sapling commands feel way more snappy and pleasant to use.

Re: Sapling: A new source control system with Git-compatible client

#102

Post by Shish2k »

chungy wrote: post #13

> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.

I use HEAD as my staging area, and do all the normal staging-area things, but without the weirdness that comes from the staging area being a different concept to a commit (ie, the diff command Just Works, no need for a separate `--staged` flag to enable special behaviour for that case)

Re: Sapling: A new source control system with Git-compatible client

#103

Post by xctr94 »

lolinder wrote: post #60
sequoia wrote: post #50

Phabricator[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

I have my doubts as to whether they can be a good citizen of the open-source community and respect the developers relying on their tools. I routinely see bugs marked “won’t fix” and nonsensical new features in the React Native ecosystem.

Re: Sapling: A new source control system with Git-compatible client

#104

Post by durham_meta »

thijser wrote: post #96
durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

The GitHub repo says that Mononoke and EdenFS is "not yet supported publicly". The code seems to be all in the open source repository though, what does the "not supported" mean here?

The code is available to see, but they don't necessarily build in an external environment yet and even if they did we aren't ready to support them being used externally. Hopefully we can support them one day, but for now we're just starting with the client.

Re: Sapling: A new source control system with Git-compatible client

#105

Post by xctr94 »

vfclists wrote: post #73
sequoia wrote: post #50

Phabricator[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.

Google isn’t far behind either. Perhaps corporate-owned open-source ecosystems weren’t a great idea.

Re: Sapling: A new source control system with Git-compatible client

#106

Post by chadaustin »

thijser wrote: post #96
durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

The GitHub repo says that Mononoke and EdenFS is "not yet supported publicly". The code seems to be all in the open source repository though, what does the "not supported" mean here?

EdenFS builds (and probably runs?) from GitHub, but we have done no work to make it usable and hook it up to an existing checkout. It may not be much effort, and we're hoping to demonstrate that workflow in the future.

Re: Sapling: A new source control system with Git-compatible client

#107

Post by mitrandir77 »

ArchOversight wrote: post #47
arxanas wrote: post #41

Earlier quoted context omitted.

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…

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? Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sap…

`sl histedit` is very similar to `git rebase -i` if you're famiilar with that interface which works just fine.

Other commands useful for amending changes to previous commits:

* `sl goto --merge ` - if theres no conflicts you can just switch commits with pending changes and those pending changes would be applied on top of other commit. If there are conflicts this command would fail https://sapling-scm.com/docs/commands/goto

* `sl absorb` - this automagically finds the last commit that touched the lines that are pending and amends that commit with them https://sapling-scm.com/docs/commands/absorb

Re: Sapling: A new source control system with Git-compatible client

#108

Post by [deleted] »

stevage wrote: post #87

Thank god. 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 dis…

[deleted]

Re: Sapling: A new source control system with Git-compatible client

#109

Post by waynesonfire »

stevage wrote: post #87

Thank god. 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 dis…

No post body was provided.

Re: Sapling: A new source control system with Git-compatible client

#110

Post by jordigh »

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.

Post reply on HN