Live data from Hacker News

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

engineering.fb.com

181–190 of 543 posts

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

#181
post #70

Earlier quoted context omitted.

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.

I think zstd is originally not a Facebook project. https://fastcompression.blogspot.com/2015/01/zstd-stronger-c... I believe Yann Collet, author of lz4, eventually went on to work for Facebook and finished it there.

https://www.wired.com/2016/08/facebook-just-proved-isnt-hool... He was hired by Facebook during the 2015 summer, but the zstd announcement is dated jan 2015.

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

#182
post #159
post #153

FYI, as-shared at Meta: > First things first, please go to your phone and turn off wifi to avoid voter ring detection and upvote us on Hacker News!

Do you have any actual evidence of this, or is it a baseless accusation?

I didn't make it up, if that's what you're asking. Any Meta employee can confirm: fb.workplace.com/groups/scm.fyi/posts/2705323112933543

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

#184
post #162
post #48

Earlier quoted context omitted.

It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. We develop HighFlux[1] which also gets rid of the staging area. It simplifies your mental model of what's going on a lot. Because everything you save is automatically committed, switching to a different task/branch is also always instant without needing stash. Because what you're testing locally is what you're co…

> It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. Sorry, but no. "No staging area" is what VCSes were like before Git and it was worse, much worse.

Would support that. The staging area is one of the things that make Git shine, imho.

It would be very difficult to handle quite some "WIP situations" without the staging area.

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

#185
post #88

Earlier quoted context omitted.

HHVM is an interesting data point too - kept PHP compatibility for as long as there were significant open-source users (eg wikipedia), but after PHP7 caught up with a lot of the performance gains, meaning there was little reason to use HHVM in PHP-compatibility mode, they then went off in their own direction with Hacklang (which is still actively developed) to get all the benefits of being PHP-like without the drawba…

>get all the benefits of being PHP-like without the drawbacks of being PHP-compatible I have a hard time understanding the benefit of using a language that’s almost like a very popular one, but not quite.

PHP has some benefits to its design that the vast majority of other languages don’t — deployment is as simple as “stick a .php file on in your website folder”, hitting the “refresh” button gets you the latest code with no “build” or “restart server” step, it’s all stateless shared-nothing so you won’t have data from one request changing the behaviour of another request, etc.

But the implementation has a lot of drawbacks - the language is painful, typing is bolted-on and still incomplete after years of work (eg there are no typed arrays), the standard library is an inconsistent mess thanks to its origins of “take several other language’s standard libraries and duct-tape them together”, etc.

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

#186

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 fro…

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.

From the repo readme:

> The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.

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

#187
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…

[deleted]

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

#188

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 fro…

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 :)

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

#189

Earlier quoted context omitted.

It stems from the original Mercurial implementation. The goal here is that every operation leaves the repository in a good state that can be pushed/pulled. That's why Mercurial and Sapling rely on commit/amend/uncommit, etc and for example usually discourage the use of interactive rebasing in favor of restack and other operations that add another "state". It facilitates the mental model for developers without actuall…

As I understand it restacking is rebasing no?

Yup, it's automatic rebase of a commit on top of the newer (amended) version of its parent.
Post reply on HN