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

381–390 of 543 posts

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

#381

Post by colonwqbang »

jupp0r wrote: post #285
jedberg wrote: post #26

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

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.

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.

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

#383

Post by O_H_E »

alwillis wrote: post #301
Shish2k wrote: post #8

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

Wait—there’s a FB fork of Mercurial? Would love to know more about it!

That is this post. Sapling.

GP was probably talking about a time when they used it internally but maybe it didn't have a name by then.

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

#384

Post by saagarjha »

astrange wrote: post #374
kmavm wrote: post #217

Earlier quoted context omitted.

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

It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.

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

#385

Post by esjeon »

The UI sounds much better than git. (but what can be worse than git in the first place?!) It's solving (or trying to solve) many common griefs of git. I don't like Meta, but I find myself enjoying the design itself.

I especially like the idea of stack. It's not something git can't do, but someone should've spent quite some time on tons of trial-and-error to nail the workflow. It's certainly a well aged project - a decade old! Kudos to that.

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

#386

Post by astrange »

saagarjha wrote: post #384
astrange wrote: post #374

Earlier quoted context omitted.

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

It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.

Note WhatsApp had 35 employees when they were acquired and Instagram had 13. At that size you need to be productive at managing servers but you're probably not thinking how great it'd be to have a "whole new programming language and source control system" team.

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

#387

Post by pmeunier »

elric wrote: post #354
hgomersall wrote: post #118

Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).

There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. I'd r…

> A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically.

In Pijul, patch authors are public keys and patches are signed by default. The link with an author's identity is done outside of the patches to allow for changes in name or email address.

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

#388

Post by maccard »

jupp0r wrote: post #285
jedberg wrote: post #26

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

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?"

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

#389

Post by saagarjha »

astrange wrote: post #386
saagarjha wrote: post #384

Earlier quoted context omitted.

It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.

Note WhatsApp had 35 employees when they were acquired and Instagram had 13. At that size you need to be productive at managing servers but you're probably not thinking how great it'd be to have a "whole new programming language and source control system" team.

WhatsApp and Instagram at the point of acquisition were simpler than Facebook is (and was), or even compared to what it is now. Once you scale you start to need a lot of engineers to help keep things standing up and everyone on the same page.

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

#390

Post by pmeunier »

softjobs wrote: post #29
noahchumsky wrote: post #11

Earlier quoted context omitted.

You may find https://pijul.org/ interesting.

And https://github.com/martinvonz/jj .

Because it is based on Git, jj is not a CRDT, it seems to be a better merge algorithm (even though the details on their algorithms are scarce).

When I say "not a CRDT" I'm obviously talking about HEAD not being a CRDT, a Git repo is append-only, so the history of a Git repo actually is a CRDT (but that's not what the comment above meant).

Post reply on HN