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

331–340 of 543 posts

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

#331

Post by Too »

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

In git you do this like git commit --fixup hashtofix && git rebase -i --autosquash hashtofix^

Hard to discover and remember but once you do it usually works smoothly.

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

#332

Post by durham_meta »

bentcorner wrote: post #327
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.

Hopefully a dumb question that I missed an answer for in the docs. If I have an existing git repo (not hosted on github), is there a way to try using sapling with it? Or do I need to clone it from scratch? My impression from the blog post is that I can use sapling and have everything "look" git-like from the remote repo's point of view.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

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

#333

Post by durham_meta »

epage wrote: post #205
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.

Looks like you are using clap v2? Feel free to ping me for help on moving to v3 then v4. I expect the rate of breaking changes to be slowing down and to be smaller in scope (from the users perspective) so now is a good time. Id love to hear how we can make clap better fit cases like this and how we can help in improving the UX of applications.

We're somewhat limited by what version of clap is available in our internal monorepo. We try to keep things reasonably up-to-date though, so I'm sure we'll upgrade at some point.

I believe we actually only use clap for some side binaries, not for the main sl executable. We have a custom parser for that (https://github.com/facebook/sapling/tree/main/eden/scm/lib/c...), to match the preexisting hg parse behavior. Unfortunately I'm not familiar enough with clap or why we didn't go with clap in the first place to say what we would need to use clap for the main binary.

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

#334

Post by durham_meta »

neandrake wrote: post #267
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?

Unfortunately you can't use Sapling with Mercurial repositories. There are too many differences at this point.

This does not use hg-git under the hood. Sapling's internal structure differs from Mercurial in substantial ways, and we've built some cleaner layering that allowed us to shim Git in under our storage layer. This also means that we read and write directly to the git repo, instead of duplicating and importing all the data like hg-git did. This has some nice benefits, like the hashes you see in the output are actually Git hashes.

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

#335

Post by [deleted] »

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…

[deleted]

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

#336

Post by durham_meta »

dastbe wrote: post #319
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.

can you speak to commit throughput of the sapling server? While there's tooling to make git scale better (like sparse checkouts) scaling commit throughput for automation is a pain.

Unfortunately we can't really talk too much about that at this point. I can say a lot of effort has gone in on the server side to optimize commit throughput though.

One example we mention in the blog post is that when you push, it doesn't actually need to be a fast-foward push (using Git terminology) to succeed. Our server can rebase the commit on top of the destination bookmark for you (with some limitations, like not merging file contents). This allows many people to push, and not have to race to rebase. Then we have substantial optimizations around the critical section of final-rebase-then-move-branch-forward, which yields pretty good throughput.

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

#337

Post by fhd2 »

bogwog wrote: post #58
fhd2 wrote: post #24

Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions. Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases…

Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them. ...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence t…

Good points. Personally, a lot of the appeal of open source is not so much about having free stuff, it's more about being able to learn from others. I learned a ton from the various engines Id Software released back in the day, but have no expectation that they maintain them.

If it comes to stuff I actually want to _use_, I avoid projects backed by a single or a few companies - like Sapling. So from that angle, I'm not particularly impressed either.

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

#338

Post by zemnmez »

rockwotj wrote: post #247
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…

Check out jj, it's made by someone who works on Google's source control https://github.com/martinvonz/jj

I have been looking for something like this for so long!

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

#339

Post by sa1 »

arxanas wrote: post #35
lijogdfljk wrote: post #31

Earlier quoted context omitted.

I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit. I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed. Stage + Unstaged is my working area, and the two live toge…

In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).

I’ve never used one of the source control systems at these big companies but I use the staging area along with your git-branchless just fine for now. I’m not sure if it’s any less efficient this way.

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

#340

Post by quark12 »

neandrake wrote: post #267
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?

https://sapling-scm.com/docs/internals/internal-difference-h... briefly explains the Git support. Currently we keep trees and blobs in a git bare repo unchanged, but convert the commit graph to our format so we can run our own graph algorithms. In the future we might store trees and blobs differently too.
Post reply on HN