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

281–290 of 543 posts

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

#281

Post by neandrake »

krick wrote: post #269

I'm kinda surprised by the excitement it gets. I'm still looking for a compelling explanation, why I (or anyone else) should even bother? I am a git hater myself. I mean, git just sucks. It always did, and it always was much worse than Mercurial. When they could have be seen as competition, I was forcing Mercurial as much, as I could, but then GitHub became a thing, and after a very short struggle it became just hope…

Facebook was a large contributor to Mercurial for a number of years [0]. They wanted to contribute to making Mercurial scale but it seems like they wanted to move faster and/or in a different direction than the Mercurial team wanted. Funnily I think they originally chose Mercurial for essentially hitting those same roadblocks from the Git community. Instead of continuing to contribute to Mercurial they forked and continued working on it internally, now released as Sapling.

Many companies/organizations won't hit the size/scale where this matters but there are certainly plenty of companies who have large repositories and contributors that would benefit from something like Sapling over Git/Mercurial. These tools start to become slow. Many addons have been created to ease the problem (LFS or Microsoft's VFSforGit, narrow/shallow checkouts, etc.) but they also add complications (LFS especially in my experience). Monorepos have their advantages [1], and even with disadvantages they exist and won't go away. It's more appealing to migrate a monorepo to a new tool that adds more benefits specific to monorepos than to break apart a monorepo into separate repos.

The architecture that's being moved into seems to be less decentralized which is what Git/Mercurial were initially pioneering. I believe Google has essentially also built their own server-side SCM [2] and made Git/Mercurial clients (or wrappers for a client). I believe Microsoft did something similar forking Git and/or making their own server-side SCM but I don't recall where I came across that.

[0] https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

[1] https://trunkbaseddevelopment.com/monorepos/

[2] https://www.quora.com/Why-do-Google-employees-use-Piper-inst...

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

#282

Post by UncleEntity »

nulltype wrote: post #254
peteradio wrote: post #216

Earlier quoted context omitted.

Lol wut. Github's success is in being a remote code repository.

So your claim is that GitHub would be equally successful if their website was just information about how to push to a git remote hosted by them?

SourceForge was pretty successful back in the day and they were pretty bland compared to GitHub.

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

#283

Post by [deleted] »

krick wrote: post #269

I'm kinda surprised by the excitement it gets. I'm still looking for a compelling explanation, why I (or anyone else) should even bother? I am a git hater myself. I mean, git just sucks. It always did, and it always was much worse than Mercurial. When they could have be seen as competition, I was forcing Mercurial as much, as I could, but then GitHub became a thing, and after a very short struggle it became just hope…

[deleted]

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

#284

Post by MikusR »

TillE wrote: post #119
aliveli wrote: post #72

Earlier quoted context omitted.

Don't forget projects like PyTorch, Presto, etc.

zstd is fantastic, though I suppose it's not the sort of thing that particularly needs ongoing active maintenance.

You would think that, but then you look at its release notes.

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

#285

Post by jupp0r »

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.

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

#286

Post by Tomis02 »

riquito wrote: post #268
jkaptur wrote: post #251

Earlier quoted context omitted.

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.

Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.

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

#287

Post by xyzzy_plugh »

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible?

None of this makes any sense to me.

> Local branch names are optional.

As are they in git, just hang out with a detached HEAD.

> There is no staging area.

Practically the entire world sadly invokes `git commit -a` anyways and you still have to add untracked files.

Neat project but I don't get what this is solving for.

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

#288

Post by neandrake »

lolive wrote: post #280

I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch. I agree that the Git commands are pretty primitive (aka low-level). But eventually you can learn the good patterns and deal with that. For me, the big question is how to manage a monorepo (with zillion of branches) so you can express which set of branches are relevant to your current concern at time T: - fo…

I've worked with Mercurial repos for 10+ years and only recently we've been migrating some of the smaller repos to Git primarily due to better supported tooling. Mercurial has done a great job in specific workflows especially with phases (which not everyone adopts) -- by default they disallow modifying public commits but allow modifying draft commits. I don't believe Git really has a similar concept, or at least not integrated at the same level. I recently read about `git push --force-if-includes` which seems like it's trying to address similar situations but mostly guessing based on comparing changesets present between two repos.

To your question about what/how Mercurial helps I'm guessing it's related to this, or other workflows enabled by Mercurial's Evolve/Topic features. It sounds like Sapling has adopted Evolve/Topics and making them functional on Git repositories though I'm not sure what it's doing under the hood.

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

#289

Post by chungy »

alwillis wrote: post #215
still_grokking wrote: post #184

Earlier quoted context omitted.

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.

I think there’s some Stockholm Syndrome [1] thing going on with the staging area. It confuses noobies and it’s easy to make mistakes. I think we’ll be okay with this stack workflow [2] taken from Mercurial’s Evolve command [3]. [1]: https://en.wikipedia.org/wiki/Stockholm_syndrome [2]: https://sapling-scm.com/docs/overview/stacks [3]: https://www.mercurial-scm.org/doc/evolution/tutorials/topic-...

> I think there’s some Stockholm Syndrome

I lived through the alternative and the staging area is superior. If it wasn't, I might not be using Git, or at least begrudge when I have to; neither is the case.

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

#290

Post by xyzzy_plugh »

otikik wrote: post #202
waynesonfire wrote: post #109

Earlier quoted context omitted.

Quoted post unavailable.

GitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.

GitHub's UX is so incredibly terrible. Pull Requests are horrible -- even mailing lists are better and that's impressive.

GitHub's UX is so bad it has indeed generated a whole industry of out-of-band review tools.

Post reply on HN