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

371–380 of 543 posts

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

#371

Post by elric »

hgomersall wrote: post #369
elric wrote: post #354

Earlier quoted context omitted.

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.

Two issues:

1. You could retroactively sign something with an expired key and rewrite history

2. The one doing the conflict resolution signs the whole merge commit, but didn't author the stuff they're signing.

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

#372

Post by hgomersall »

elric wrote: post #371
hgomersall wrote: post #369

Earlier quoted context omitted.

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.

Two issues: 1. You could retroactively sign something with an expired key and rewrite history 2. The one doing the conflict resolution signs the whole merge commit, but didn't author the stuff they're signing.

1. I accept there's a requirement for a second level of verification on the signature, but I can't see how that's avoided in any scenario (that is, the signing is orthogonal to the verification).

2. That's the point though. The person doing the commit takes responsibility. The individual commits are still there before the merge (including signatures), so there's no loss of responsibility or credit before the merge.

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

#373

Post by brundolf »

still_grokking wrote: post #167
mikepurvis wrote: post #143

Earlier quoted context omitted.

git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.

What's wrong with just working on and when the changes finally look like they should just do a `git commit --amend`? Or if the commit should for some strange reasons really never exist just move HEAD one commit back. You could even get the changes back by merging the "bad" commit back without committing the merge (using the `--no-commit` switch).

I think you're demonstrating the original point

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

#374

Post by astrange »

kmavm wrote: post #217
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.

Facebook developers seem to have a surprising amount of free time to go around reinventing things that are not obviously social network features. (Or to have had it in the 2010s, at least.)

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

#375

Post by ShredKazoo »

agumonkey wrote: post #213
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.

The social inertia point is an interesting one. It seems like in some areas, like JavaScript frameworks, there is a ton of inertia for change; in other areas, like git, there is a ton of inertia for stasis. Why is that?

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

#377

Post by astrange »

reissbaker wrote: post #244
waynesonfire wrote: post #237

I just cannot understand how a CTO approves this type of project. Imagine running a company and some engineer comes in and and says they want to develop a new source control system. I don't understand under what circumstances this is approved. Is it a pet project for a 10x engineer and it's allowed just to keep them on board? There are projects, like Apache Hadoop, that are open-sourced because they're an open-source…

The simple reason is that Mercurial and git were way too slow for large repos, and FB wanted a monorepo for productivity reasons. It's cheaper to fund this project than reduce engineering productivity by even 1% at the scale of FB. Google did exactly the same thing, but hasn't open-sourced their tools. Projects to drive incremental productivity make not a lot of sense for small companies, but become immensely valuabl…

Just as "inventing your own source control system" is a hobby, "being a very large engineering organization" is a hobby.

FB and Google started with infinite money spigots and used it to hire a lot of people who make a lot of commits; if you laid them off, or if you canceled half the remaining Google products they haven't already canceled, not all that much would change.

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

#379

Post by jsmeaton »

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.

Does sapling support hooks like pre and post commit? My workflow leans on pre-commit (the framework) heavily and it would be hard to give that up. I’d still be keen to take this for a drive though, nice work!

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

#380

Post by Kwpolska »

msarnoff wrote: post #61

Command name conflicts with the `sl` utility that has existed for decades. https://github.com/mtoyoda/sl

I would be more concerned about the ease of mistyping `ls` as `sl`, especially if you tried to list a directory whose name is a destructive Sapling command.
Post reply on HN