Live data from Hacker News

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

engineering.fb.com

131–140 of 543 posts

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

#131
post #20

I'm not interested in a simplification of git, sorry. Git's major value proposition is that they added moving parts until the system worked great . If you don't want named branches, staging, or any other piece of the ideology, then subversion is a fine choice. But most folks moved on from svn for reasons

Reasons being the projects that found cool to use git, because Linus made it, and now regardless of my opinion, I have to deal with git.

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

#132
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…

Phabricator has a fork which is still developed: https://phorge.it/

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

#133
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…

Maybe I'm misunderstanding, but isn't this what `git revert` is for? Harder with an amend due to having to get the difference of commits within the reflog, sure.

That’s actually not what git revert does, hence the poor usability of its API.

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

#134

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

Is it possible to use git commands on an sl checked out repository, or vice versa? Or at least get something close enough to a git repository that I could run git commands on it, so I can fake it for internal tooling?

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

#136
post #41

Earlier quoted context omitted.

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which…

If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke. It sounds like I would need to: - switch - amend the commit - restack? - switch back to the HEAD? Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sap…

`sl absorb` can turn that workflow into a single command in many cases: it automatically looks at what hunks you've changed and tries to propagate them back to earlier commits in the stack that touched those same hunks. It's not perfect, but in my experience using this at Meta, it does what you want 90% of the time.

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

#137

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 was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.

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

#139

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 was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.

Yeah, the old Eden repository redirects directly to Sapling now: https://github.com/facebookexperimental/eden

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

#140
post #127

Earlier quoted context omitted.

Mercurial revsets and phases are two killer features of mercurial that blows any counterpart git has out of the water. Phases are a property of revisions that essentially let you know their state. By default, there are three phases: public, draft, and secret. You can't rebase a public revision, nor can you have a public revision with a secret parent. So you get out of this concept things like safe rebasing, or barrie…

Why do you want to? Not trying to be snarky, but I've been using various source control tools for closer to 20 years than 10 and I can't remember when I've ever needed or would have benefited from revsets. I'm genuinely curious what problem this solves and whether I've just never experienced or have made my own hodge podge solution for it incidentally.

I am used to working in large repos (>100 commits/day), which generally means that something like 'git log --graph' contains a lot of extraneous information.

The most common workflow I have is that I've got a couple of old working branches (like featurea and featureb), and I want to see if I need to update featureb to a newer head or not, or if featureb was based on featurea or featurea-v2. A demonstration of this kind of thing is 'hg wip' here: http://jordi.inversethought.com/blog/customising-mercurial-l....

Another thing I would use revsets for is answering queries like "which of these changes that's on the public repository made its way into the internal repository (which periodically merges from the public repo)?"

Post reply on HN