Live data from Hacker News

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

engineering.fb.com

361–370 of 543 posts

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

#361

Earlier quoted context omitted.

> started to demand that the Mercurial project work the way that Facebook wanted Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...

> Why does it have to be like this? Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you. People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement.…

> Because motivated, high performing people need to have control over their own destiny.

This opinion seems to be peculiar to software and I think it has something to do with the fact that software is one of the few verticals where you can (attempt to) intellectualize everything.

Having control over your own destiny in any other skilled labor job seems to be 98% about finding a brand and model of tool that works the way you do, and 2% building your own tools or jigs for that specialty task nobody thought to build a tool for.

In software it's anywhere from 90:10 to 10:90 depending on how much emotional baggage your coworkers are carrying around.

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

#362

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

It seems this is still based on changing history - Does hg have something to address the downsides of rebasing that are present in git? such as chilling effect on cooperation of branches (eg you don't dare touch or use remote branches which someone may use rebase on, and destruction of actual history for use in eg reconstructing a timeline of a bug and fix later found to be important).

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

#363

Earlier quoted context omitted.

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

Holy crap that looks incredible. I can't wait to try this.

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

#364

Earlier quoted context omitted.

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

Just learned about 'git absorb' couple of weeks ago and have used it every day since. Amazing tool.

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

#365

Earlier quoted context omitted.

> Why does it have to be like this? Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you. People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement.…

Does it have to be so disrespectful, though? Demanding things, getting frustrated when denied and ghosting the original project to the point even they are surprised when a fork shows up?

There is always too sides to a story. We don't know what pressures the FB engineers were under and the problems they were trying to solve resulting in them "demanding" changes. In the end I think everyone wins with the forking.

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

#368
post #356
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)

dude, vscode git interface is ... not really good. I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo

I'm talking about the available commands, the UI is purposefully minimal.

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

#369
post #354

Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).

There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. I'd r…

I don't see why the git way is problematic. It means someone is verifiably taking responsibility for all changes. That applies to conflicts and reading as much as normal commits.

Edit: I'm not saying there's not a better way, just that I don't understand the problem with git.

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

#370
post #50

Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it…

Does Facebook/Meta still use Phabricator internally?
Post reply on HN