Live data from Hacker News

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

engineering.fb.com

491–500 of 543 posts

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

#491
post #466

Earlier quoted context omitted.

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

That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things re…

The big baddie here, IMO, isn't even git itself but GitHub. Many younger devs don't even seem to realise that they're not the same thing, that git can be used without GitHub.

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

#492

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.

I don't quite buy this: Those same "motivated, high performing people" don't seem to have anywhere near the same "need to have control over their own destiny" when it comes to the commercial closed-source tools they use.

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

#493
post #466

Earlier quoted context omitted.

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

That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things re…

> Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard

That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and complaining, if it was done at all.

The reality is we only think this because we saw people do this, at great cost of their own time -- but that's the literal definition of survivalship bias. For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.

More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever. Whether this is good or bad is up to you, but you don't need to make up claims about developers being epic journeymen in the past and mastering 50 version control tools to do a single days work. They did not.

> Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.

Sorry, but I consider this to be a similarly made up claim that's just sour grapes. I've been using GitHub since 2008, I'm one of the first users. GitHub didn't even have "gamified" social features until the past 3-4 years IME (what, stars are about it?), and before that its product was pretty poor in some key areas like code review and project management, org permissions, on-prem control, etc. I didn't even use GitHub commercially until like, 2018, because most orgs had setups that were better in some key areas. But it was pretty easy to use and get started with, which mattered, and still matters, and soon enough nobody could compete with the same ease of use for free projects.

If I had to "blame" "someone" in this vein, a better place to start: global monetary and fiscal policy for the past 20 years resulting in software development becoming one of the only places with rising wages to meet cost of living demands in places like the US -- resulting in an influx of new blood to increase their wages and quality of life, combined with political choices like low interest rates, and huge explosions in demand for software devs for things like VC adventures, etc. Subsequent developments like bootcamps designed to churn devs out to match rising demand, etc which solidified platforms like GitHub further as it was easier for them to paper over these fundamentals when there was a clear winner (git/github) to focus on and ignore everything else. Forest vs trees and all.

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

#494

Earlier quoted context omitted.

> 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 su…

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

No, I mean that the filesystem I edit code in has a full snapshotted history of every save and I can recover to a particular revision or particular point in time, even one's that weren't committed to vcs[0]. I guess you can call that a "backup", but like it's not what people usually mean.

I have used this to recover some things I was working on three months ago but ended up throwing away.

(citation:

> All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review.

via https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...)

> It's easy to end up with hundreds of files changed.

Sure, doing a rename can touch 100 files, but you should isolate that change to a commit and PR that don't do anything else. Running sed and then committing or using your IDE's refactor feature, and then committing and running tests doesn't require a staging area.

[0]: The truly wild thing about this is that the vcs state is also stored in the snapshotted, point in time recoverable fs, so if you do the equivalent of absolutely botching your git history, you can jump back in time a few minutes and start from a known good state.

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

#495

Earlier quoted context omitted.

> conflicts are stored in commits (so rebases always succeed) Is this pushed to the remote when running as a git porcelain?

No, the CLI prevents that because the remote is unlikely to know how to interpret conflicts. In a future where the remote understands conflicts, then you'll be able to push conflicts to a remote and collaborate on the conflict resolution.

Ah that's a pity, but totally understandable.

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

#496

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

> Because motivated, high performing people need to have control over their own destiny. I don't quite buy this: Those same "motivated, high performing people" don't seem to have anywhere near the same "need to have control over their own destiny" when it comes to the commercial closed-source tools they use.

Really?

I’ve seen people reinvent the wheel all over the place because their tools weren’t quite working for them. This instinct is the reason most good software has APIs - so you don’t have to ditch the tool entirely to customise it to your workflow. And most medium to large companies have all sorts of wacky customisations on top of existing software.

Eg perforce at Google. Well, everything at Google. And a friend at a big broadcaster has a bunch of company specific plugins for Reaper for their audio editing pipeline. And everyone insists on customising Jira.

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

#497
post #466

Earlier quoted context omitted.

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

That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things re…

I'd add on that a tools ecosystem integrated with git/hub over other options has also made git adoption a more natural fit for those who are less about tools and more about a particular outcome, which also spanned git usage (or git as a background vcs) beyond just software developers.

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

#498
Not sure if anyone has tried this yet... but the example tutorial does not work.

    $ sl clone https://github.com/facebook/sapling
    $ cd sapling
    $ sl
    @  fafe18a24  23 minutes ago  ricglz  remote/main
    │  migrate packer to new CLI framework
    ~
From [0] under "Cloning your first repo". I get the following:

    ~/sapling (main)> sl status
    abort: '/full/path/sapling' is not inside a repository, but this command requires a repository!
    (use 'cd' to go to a directory inside a repository and try again)
Hopefully this does not assume we are authenticating with GH just to clone and see sl operating?

[0] https://sapling-scm.com/docs/introduction/getting-started/

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

#499

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD.…

> Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity?

But this is mercurial. Or rather, it's mercurial rebased on top of the git data store, and it's a fork with breaking changes so it has a different name.

I do agree that the requirement to be online gives me pause. But I guess I don't know how much of a problem that would be in practice, since there's a mystery subset of functionality that works disconnected.

> Neat project but I don't get what this is solving for.

For us external people, it seems like it's mostly for using the hg interface with a github-hosted repo. The internal reason appears to be scalability to massive monorepos. Since I much prefer the hg interface to the git interface, I'm good with both of those motivations.

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

#500
post #357
post #58

Earlier quoted context omitted.

Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them. ...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence t…

> As far as oss goes, I think Google is the best. Better than Microsoft? I don't think I've ever been able to talk to a human at Google, whereas with Microsoft, I get feedback very quickly on issues and pull requests. Does Google even interact with people with open source? For example, I am using Skia via SkiaSharp, and the only place I know of to go for Skia help and issues is their Google Groups page, a website out…

This took me about 5 seconds to find: https://bugs.chromium.org/p/skia/issues/list via https://skia.org/docs/dev/contrib/#report-bugs.

> I'm not even really sure what Google does in open source.

Kubernetes (and a bunch of the offshoots), golang, a bunch of ML things, etc. It's just that many have independent foundations (CNCF) running them now to keep project management independent from a single company.

Post reply on HN