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

271–280 of 543 posts

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

#271

Post by Shish2k »

tambourine_man wrote: post #231
Shish2k wrote: post #185

Earlier quoted context omitted.

PHP has some benefits to its design that the vast majority of other languages don’t — deployment is as simple as “stick a .php file on in your website folder”, hitting the “refresh” button gets you the latest code with no “build” or “restart server” step, it’s all stateless shared-nothing so you won’t have data from one request changing the behaviour of another request, etc. But the implementation has a lot of drawba…

Yes I’m well aware of the problems. I just seems to me that being PHP-like but incompatible is much more confusing than useful.

“PHP-like but incompatible” isn’t in itself a useful feature — it is the thing which unlocks a bunch of useful features (a sensible standard library, sensible list/dict datatypes, typed collections, XHP, async functions, generics)

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

#272

Post by yCombLinks »

lawgimenez wrote: post #246
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…

React Native hasn't yet reached v1.0. Or several critical issues hasn't been addressed yet as of now.

React Native, named after their open source project that is incredibly successful, widely used, completely reshaped the front end dev world, etc... Not sure if an offshoot of a world class project not gaining traction is a mark against them.

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

#274

Post by MikusR »

lawgimenez wrote: post #246
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…

React Native hasn't yet reached v1.0. Or several critical issues hasn't been addressed yet as of now.

There recently was a thread here on the impact of layoffs on React. And apparently even Facebook has abandoned react for anything but internal projects.

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

#275

Post by jkaptur »

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.

No, I started with SVN and (briefly) VSS. I did use git for a while before hg, though, so I guess what you’re saying is possible.

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

#276

Post by kyrra »

mitrandir77 wrote: post #183

Nobody commented on the web interface yet which I think it's one of our coolest features: https://sapling-scm.com/docs/addons/isl

I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.

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

#277

Post by srcreigh »

mikepurvis wrote: post #114
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…

My brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard ", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh. So yes, in short I agree.

Isn’t this just git reset —soft HEAD~1?

Put my stuff from the last commit back into working directory?

Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.

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

#279

Post by WookieRushing »

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…

Its like Fish shell vs Bash shell.

Bash has weird defaults so you end up googling for everything. In fish, it just works and you barely need to search for anything.

Sane defaults matter. With hg, I don't need to struggle to get it to do what I want, it just gets out of the way. With git, sure it works but like you said it has a bunch of ducktaped tools together that change the defaults or just generally make things easier.

Now hg is half the pattern here. The other half is stacked commits. Each commit should build and get reviewed separately. There isn't any waiting for reviews on each commit, they all get reviewed over time and you rebase any changes that are requested. With git this is amazingly painful and half my zshrc is about making this simple. With hg, it just works. Take a look at hg absorb or hg split, theyre features built on top that yeah can replicated in zsh scripts but its kind of nice when you can assume they just work. It means junior engineers don't spend hours trying to fight git with stacked diffs.

Sapling is trying to fight the network effect here by doing the classic built a compatible but legitly better front end. Compatible with github but sane defaults is a BIG thing.

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

#280

Post by lolive »

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:

- focusing on the dev of a given set of features,

- frozing them into a delivery,

- pushing a stable monorepo+that frozen delivery to your validation platform,

- once validated, integrating that frozen delivery to one of the master branches of the monorepo,

- management of the many master branches corresponding to each subparts of the monorepo into a supermaster branch

Does this tool (or Mercurial in general) help with all that mono-repository branch management ?

Post reply on HN