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

401–410 of 543 posts

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

#401

Post by guytv »

chungy wrote: post #289
alwillis wrote: post #215

Earlier quoted context omitted.

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

> I think there’s some Stockholm Syndrome I lived through the alternative and the staging area is superior. If it wasn't, I might not be using Git, or at least begrudge when I have to; neither is the case.

Isn't the staging area just a stack of changes where stack height == 1?

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

#402

Post by guytv »

thijser wrote: post #48
chungy wrote: post #13

> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.

It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. We develop HighFlux[1] which also gets rid of the staging area. It simplifies your mental model of what's going on a lot. Because everything you save is automatically committed, switching to a different task/branch is also always instant without needing stash. Because what you're testing locally is what you're co…

One of the problems with `git`, and it seems that Sapling is no different, is that there is no one-to-one mapping between the user intent and the underlying SCM. For a user intent of "implement feature X", there is no UI to "start a new feature". Instead, one has to translate their requirement to the SCM mental model and issue a series of commands to manipulate a DAG of blob hashes that live in 4 different places simultaneously. (work tree, index, local repository and the remote repository. Highflux allows a simple user requirement to action mapping.

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

#403

Post by TuringTest »

Cederfjard wrote: post #396
saagarjha wrote: post #389

Earlier quoted context omitted.

WhatsApp and Instagram at the point of acquisition were simpler than Facebook is (and was), or even compared to what it is now. Once you scale you start to need a lot of engineers to help keep things standing up and everyone on the same page.

WhatsApp had like half a billion monthly active users when they were acquired, that could be considered fairly large scale, no? But I agree with your point in general.

Yes, but WhatsApp is a point-to-point communication tool with mostly small groups. Each individual message doesn't need to be distributed to a potentially very large audience like in Facebook, making processing and coordination of nodes smaller and simpler.

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

#404

Post by guytv »

MrWiffles wrote: post #242
dcow wrote: post #238

What exactly does “git compatible” mean? I may have missed it, but didn't see it skimming the post.

I’d like more detail on this too. I’m interpreting this to mean that anything you can do with git, you can do with sl, but I wonder what limitations exist for that. There have got to be some, somewhere along the way. Even just edge cases! Is it as simple as swapping ‘sl’ for ‘git’ in your terminal and workflow and nothing else changes? Surely not…

You `clone` your git repository into Sapling. You can then only use the sapling tooling (CLI) until you `push` to GitHub. You can't use `sl` and `git` or git GUI/ IDE plugins on the `sl` clone.

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

#405

Post by FerociousTimes »

fulafel wrote: post #362
alwillis wrote: post #168

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

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

For the uninitiated, hg, in this context, refers to Mercurial by the chemical symbol (Hg) for Mercury.

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

#406

Post by Varriount »

Tomis02 wrote: post #286
riquito wrote: post #268

Earlier quoted context omitted.

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.

Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.

Can you elucidate? What did you find appealing/unappealing?

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

#407

Post by raimue »

jordigh wrote: post #345
Too wrote: post #331

Earlier quoted context omitted.

In git you do this like git commit --fixup hashtofix && git rebase -i --autosquash hashtofix^ Hard to discover and remember but once you do it usually works smoothly.

No, the point is that you don't have to mention the hash at all, it's automatically deduced by diff context.

There is git-fixup, which provides the 'git fixup' command that makes suggestions to which commit the currently staged changes should be added.

https://github.com/keis/git-fixup

git-fixup will add fixup! commits, so it still needs the mentioned 'git rebase -i --autosquash' afterwards. Usually you do not even need to give it a specific commit if your branch is set to track an upstream branch.

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

#408

Post by nailer »

itslennysfault wrote: post #33
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.

Somehow that doesn't matter for FB. Yarn is not 10x better than NPM and it took off. React is.... ugh... React and it took over the whole dang industry.

> Yarn is not 10x better than NPM and it took off.

Did it? I think it had a short lived period of popularity when npm wasn't deterministic and is now mainly a novelty.

> React is.... ugh... React and it took over the whole dang industry.

Agreed there. But most people hadn't seen components before, they really were 10x better than MVC approach, even for all of React's complexity.

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

#409

Post by Double_a_92 »

matheusmoreira wrote: post #292
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…

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

Because that's how progress slowly happens? If I have an issue with something, and come up with a possible solution, and then ask why it's not actually done like that... Either other people tell me I'm wrong and explain why, or they agree and things get better.

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

#410

Post by nemetroid »

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.

My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control.

Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.

Post reply on HN