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

211–220 of 543 posts

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

#211

Post by Shish2k »

sixstringtheory wrote: post #199
Shish2k wrote: post #192

Earlier quoted context omitted.

Nothing is perfect, but some things are clearly better than others - hence why we’re nearly-all using git rather than "learning and familiarising ourselves" with CVS :)

Fair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git. I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot. And I guess it bears repeating that I’m interested in possibility and…

Given that they’re both open source and can be customised using turing-complete languages, the only limit to possibilities is how much effort you’re willing to put into customising them. Even CVS has the possibility of working as a distrubuted system if you wrap it up in enough layers of hacky shell scripts ;)

Having done quite a bit with both mercurial (which the sapling CLI is based on) and git, I find that the mercurial approach has a lot more sane defaults, is generally less effort for the same results, and has a lot of quality-of-life improvements — like git has the possibility of doing interactive commits with `git add -i`, but sapling's interactive-commit interface actually makes it usable.

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

#213

Post by agumonkey »

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…

I don't blame git, I'm mostly surprised about the social inertia regarding improving it. But like programming languages, pressure accumulate until it's released, I'm sure sapling and similar will make people want to try new things and git will soon catch up.

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

#214

Post by alwillis »

durham_meta wrote: post #101
thijser wrote: post #90

Earlier quoted context omitted.

I'm curious about the tech stack. It seems to be a combination of Rust and Python? How does that exactly work?

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.

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

#215

Post by alwillis »

still_grokking wrote: post #184
chungy wrote: post #162

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

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

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

#216

Post by peteradio »

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.

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

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

#217

Post by kmavm »

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…

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.

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

#218

Post by anyfactor »

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…

How to not abondon a project? I would love to know that.

This is my naive understanding. A for profit company open sources a project that they have been using and developing internally. The have built a philosophy and understanding of the project as they use and develop it. Most of their action regarding the project is that they must use it and they usually don't have any other options.

Because the foundation is already laid the solution for its shortcoming is having just an understanding of them. Then you open source the project knowing that you have developed the project to it's completion.

Now comes the OSS community. Either we request features that goes against the project philosophy or we don't want to get involved because we don't need to compromise and acknowledge the shortcomings because we have options.

A good solution can be open sourcing projects that the org thinks isn't complete and needs further development without compromising security, philosophy and usability. Because if you have a list of things you need, you can ask the OSS community to fix those things rather then be critical of the foundation and philosophy.

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

#219

Post by alwillis »

1attice wrote: post #68
arxanas wrote: post #65

Earlier quoted context omitted.

In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not having them, but Git would have been better off if they consolidated into a single idea and concentrated their efforts on that. If you can remove a concept from Git and still suppor…

Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-…

On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git.

Outside of the Git fanboy bubble, developers don’t want to have to be version control experts, which once you get past a certain level of Git usage, you have to be, whether you wanted to or not.

Especially if your team doesn’t have that person who can get you out of any Git jam you may get yourself into.

It will also be much faster to get a new developer up to speed using Sapling than Git. And because it’s Git-compatible, if there’s something super advanced that can only be done using the Git command line, that’s still an option.

Telling the intern/junior developer to read the man page for git-log is a non-starter; it’s over 19,000 words!

The best thing for the greybeards is they can continue using Git while others use Sapling and commit to the same repo.

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

#220

Post by alwillis »

nailer wrote: post #9

This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.

This won’t go anywhere even if it’s 20% better than git. To replace git’s network effects, you need to be 10x better.

Nobody is trying to replace git; that’s not a stated goal. Plus git is so entrenched, it’s not going anywhere anytime soon.

However, few companies have more gigantic code bases than Facebook, which not that long ago, had their entire monorepo [1] in Mercurial, which had certain advantages over Git at the time.

So if there’s an organization that knows the pinpoints of version control, I’d put Facebook on that list. They’ve been working on approving version control at scale for more than 8 years.

As long as it’s git-compatible, the git true believers will have nothing to worry about.

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

Post reply on HN