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

261–270 of 543 posts

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

#261

Post by sweettea »

alwillis wrote: post #168
jordigh wrote: post #110

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 certainly recognized several Mercurial features and concepts in Sapling. For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling. Overall this looks promising. [1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...

Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb

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

#263

Post by rgoulter »

zabzonk wrote: post #209
jakear wrote: post #198

Earlier quoted context omitted.

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)

because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach

Taking time to consider things is good; but that doesn't mean you're better off with slow tools.

If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.

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

#264

Post by mdaniel »

glandium wrote: post #203
IshKebab wrote: post #137

Earlier quoted context omitted.

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 build instructions for sapling: "It can be built by running make oss in the eden/scm directory"

Holy hell, did they manually recreate meson? a 1700 line setup.py ... https://github.com/facebook/sapling/blob/main/eden/scm/setup...

It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable

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

#266

Post by Remnant44 »

jordigh wrote: post #110

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…

The way Mercurial is structured is, to me, intuitive, easy, and powerful. I'm still using it for all of my local projects; luckily hg-git lets you pull in dependencies from github, which would otherwise require me to switch to git.

I wish it had won the DVCS wars.

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

#267

Post by neandrake »

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.

Since the sapling client is a fork from Mercurial does that mean it can also be used with Mercurial repositories in addition to Git repositories or is that not supported?

In order to work with Git repositories is this essentially the Mercurial client using hg-git on a converted repo under the hood?

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

#268

Post by riquito »

jkaptur wrote: post #251
jordigh wrote: post #110

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

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

#269

Post by krick »

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 hopeless. There still are folks who use fossil or something, but ultimately git became THE SCM. So, yeah, I hate you, GitHub, I hate you, Linus, but I fully admit that you've won. So… now I can actually admit it isn't such a big deal.

Sure, it would be somewhat better if git never existed at all and we'd all just use a better SCM from the very beginning. But given it's just not the case, what it the problem, really? It isn't hard to learn git. I do know some people who are struggling with anything outside of simple pull-branch-add-commit-push workflow (usually performed via buttons in their IDE), but, honestly, I think they will be struggling with any other SCM just as much — it's just the difference between caring to build a mental model of the tool you use, and simply memorizing a number of popular commands. The tool isn't at fault here. So, really, git is kinda bad, but not that bad.

Monorepos? I mean, there were tools to work with them before, but does anyone outside of Google/FB actually work with repos that git cannot handle? Is it really a good idea to have such repos? I mean, it's nice that some tool can work with them, but is it actually important?

I mean, there is some new "better" SCM (often somewhat git-compatible) almost every year. But I've never actually seen anything that would make me push for that "better" SCM anywhere. Even for my personal projects. Git isn't "just git" anymore, there are countless tools that integrate with it, we all know it by heart and have sets of "best practices", how-to's, personal workflows, helper-scripts, etc. There is a huge downside to start using anything besides git, so what is the upside that would compensate for it? I never see one.

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

#270

Post by neandrake »

alwillis wrote: post #214
durham_meta wrote: post #101

Earlier quoted context omitted.

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

Sapling originated from the Mercurial open source project, which was largely Python (at the time). Just to finish up, most of Mercurial has been rewritten in Rust, although the Python version is still the default install.

It's difficult to find out information about the status of the oxidation project with Mercurial. I just noticed the 6.3 release earlier today and looked more into the rust support. I didn't get the feeling that most of Mercurial has been rewritten in Rust yet. The `hg help rust` information only lists a handful of features as gaining improvements from Rust, albeit they are likely core/essential components, as well as mentioning some/all of the work is experimental. The documentation here seems very much directed towards developers still.
Post reply on HN