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

421–430 of 543 posts

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

#421

Post by bootsmann »

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…

Tbf I think this was just the learning curve for big tech companies. Google and Facebook face scalability problems other companies 5 years before anyone else so if they don't open source the solutions they come up with, the industry-standard that establishes itself 5 years later will not be compatible with their solution and they will have a hard time recruiting and keeping personnel for their own system.

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

#422

Post by still_grokking »

alwillis wrote: post #215
still_grokking wrote: post #184

Earlier quoted context omitted.

Would support that. The staging area is one of the things that make Git shine, imho. It would be very difficult to handle quite some "WIP situations" without the staging area.

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

Which part of the stack features would replace the staging area? I see nothing in this regard. Was the right documentation site linked?

I also don't see anything that couldn't be trivially added to Git. A few lines of shell script would likely suffice. What do I miss here?

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

#423

Post by still_grokking »

brundolf wrote: post #373
still_grokking wrote: post #167

Earlier quoted context omitted.

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

And that would be?

That Git is able to handle even completely weird requirements, like making history disappear?

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

#424

Post by [deleted] »

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…

[deleted]

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

#425

Post by still_grokking »

joshuamorton wrote: post #226
still_grokking wrote: post #156

Earlier quoted context omitted.

Sounds like saying bye-bye to any meaningful history. Rebasing, cheery-picking, or reverting of commits becomes impossible when every save of a file is pushed. You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Why not go one step farther: Just make an automatic block image of the whole systems of…

> You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Google does this, it has saved my butt on more than one occasion. > Sounds like saying bye-bye to any meaningful history. I'm so confused, you just amend the most recent commit, or work with changes unstaged and uncommited. Like my normal workfl…

> > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess).

> Google does this, it has saved my butt on more than one occasion.

You mean backups? Yes, backups are a very good idea.

But this has nothing to do with VCS. That are separate topics.

> Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working

As long as the requirements are so trivial even CVS would suffice.

But even considerably simple refactorings (in e.g. static languages) can be much more complex. It's easy to end up with hundreds of files changed. Than you need more powerful tools. Doing such things without the staging area is almost impossible to get right. (The only alternative would be quite some rebase sessions; and those are way more complicated than using the staging area upfront; also you would need some way to do diffs against "pined" changes—which is something you get for free with the staging area).

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

#426

Post by nicoburns »

maccard wrote: post #388
jupp0r wrote: post #285

Earlier quoted context omitted.

Mostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of git and/or have giant amounts of binaries in their repos. Actually having Gigabytes of source code is pretty rare.

> and/or have giant amounts of binaries in their repos. Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems. Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the…

In fairness, there is git LFS, which is a well-maintained solution to do this. It's not fantastic, but it does exist.

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

#427

Post by djur »

jakear wrote: post #326
djur wrote: post #308

Earlier quoted context omitted.

Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.

The parent said: > This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is. I said that simple command already exists in VS Code. Yes it can be done via CLI, but not as simply as in VS Code. Not sure what your claim is.

What is the unamend command in VS Code?

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

#428

Post by mhw »

Too wrote: post #331
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...

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.

Or git commit --fixup=:/ to find the most recent commit with pattern in the message. Still going to give git-absorb a try though.

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

#429

Post by still_grokking »

saghm wrote: post #317
still_grokking wrote: post #144

Earlier quoted context omitted.

To be honest, I think this behavior is quite useful. Staging just means "I'm happy with the changes so far but didn't finish everything I want in my commit; let's ignore this changes for now". What `git diff` does by default becomes useful when you touch the staged changes again . Then you see only the new changes compared to the staged stuff. This helps building up a commit step by step, with some trail and error in…

I can see the behavior being useful in some cases (and not a _super_ common cause of mistakes once you learn it), but the issue for me is mainly that it's surprising and easy to get bitten by before you learn it. This describes git entire UX as well in my opinion: the underlying model is very powerful and generally pretty sound, but the API for it does a poor job of making it clear, and generally you have to make a l…

Yes, this makes sense mostly.

Git is conceptually very sane and logical. But the UX is indeed (still) terrible.

But a lot of people seem to complain about the complexity of the underlying concepts. That makes no sense to me as the concepts are complex because the problem at hand is complex. Also it makes no sense to me that people are constantly crying for a new tool even they have obviously issues with understanding the problem space and all requirements. A new tool would not make all this complexity go away! It could at most try to "hide" some of the complexity by introducing magic. This wouldn't be helpful at all as magic is way worse than bad UX, imho. Bad UX is bad UX you can deal with it. But when magic goes wrong all bets are off and you're usually in deep trouble.

This looks like people would argue to rewrite the back-end (some propose form scratch!) even only the front-end needs some face lift…

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

#430

Post by throwawaaarrgh »

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…

> I really hope that git is not the final word in version control.

common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.

deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.

same reason why it's hard to make a Facebook alternative.

Post reply on HN