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

411–420 of 543 posts

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

#411

Post by Vinnl »

durham_meta wrote: post #332
bentcorner wrote: post #327

Earlier quoted context omitted.

Hopefully a dumb question that I missed an answer for in the docs. If I have an existing git repo (not hosted on github), is there a way to try using sapling with it? Or do I need to clone it from scratch? My impression from the blog post is that I can use sapling and have everything "look" git-like from the remote repo's point of view.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

Is that a one-way street, or can I personally adopt Sapling for our Git repos without my collaborators even noticing? (For now.)

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

#413

Post by Maxious »

thiht wrote: post #395
andrewmcwatters wrote: post #66

The biggest disappointment here is surely a missed opportunity to shoehorn a git and sap joke into this release. The utility should obviously be called `sap' and not `sl'.

> git and sap joke Non native here, could you explain? I know git is a slur and sap is the "tree blood", but are there other meanings I'm missing?

alternative meaning "a foolish gullible person" https://www.merriam-webster.com/dictionary/sap

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

#414

Post by origin_path »

saagarjha wrote: post #384
astrange wrote: post #374

Earlier quoted context omitted.

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

It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.

Note though that other large projects with similar scaling-git problems tended to just write wrapper tools to work around it, see how Chromium and Android do it.

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

#416

Post by matwood »

MBCook wrote: post #232
softwaredoug wrote: post #22

Its interesting how these threads about Git simultaneously have (a) People arguing git is fine, and shouldn't be simplified (b) People arguing about the right way to use git, and flame wars about best git workflows I mean most people simply see (b) and conclude "this is a huge hassle, I don't want to annoy some git-workflow-purist, I'm just going to walk on eggshells on this tool and hope I don't break anything" It's…

You missed my problem with these threads. (c) Git is a disaster that has destroyed source control for 15+ years and the industry is unable to recover from due to Stockholm syndrome It’s impossible to discuss source control without people coming out of the woodwork to shit on git. It doesn’t work right. It’s too hard. SVN was better. Mercurial should have won. Blah blah blah. Git isn’t perfect. And the command line ha…

I agree. I think git is fine, but also would like improvements. I started with CVS and VSS (well really started with copying files to dir_bak heh), then SVN and git. Yelling across the office to tell someone to checkin a file so I could make an edit seems so quaint. VSS had a fun bug that if you ran out of disk space, it would destroy the entire repository - yup.

Is git sometimes obtuse? Sure, but it's fast and incredibly powerful. My everyday commands are easy to use, and if I need something special I go to the documentation - just like any other SCM.

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

#417

Post by bentcorner »

durham_meta wrote: post #332
bentcorner wrote: post #327

Earlier quoted context omitted.

Hopefully a dumb question that I missed an answer for in the docs. If I have an existing git repo (not hosted on github), is there a way to try using sapling with it? Or do I need to clone it from scratch? My impression from the blog post is that I can use sapling and have everything "look" git-like from the remote repo's point of view.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

Just to clarify, I meant that I've already cloned it via git. Can I just start using sapling with it or do I need to delete the local repo and re-clone it with sapling?

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

#418

Post by jordigh »

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

Yes, hg has changeset evolution. A meta-history of editing propagates when you push rewritten commits.

https://www.mercurial-scm.org/doc/evolution/

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

#419

Post by still_grokking »

guytv wrote: post #401
chungy wrote: post #289

Earlier quoted context omitted.

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

Sure. And a branch is also just a stack of changes…

The whole point is that this things are treated differently.

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

#420

Post by jordigh »

raimue wrote: post #407
jordigh wrote: post #345

Earlier quoted context omitted.

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.

Still not quite the same, because absorb splits up your working directory changes into all relevant commits, as deduced by diff context.
Post reply on HN