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

91–100 of 543 posts

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

#91

Post by ajkjk »

sdiacom wrote: post #40
saghm wrote: post #34

Earlier quoted context omitted.

My favorite example of the staging area being super weird is `git diff` behavior. By default, git diff will show unstaged changes as well as committed changes, but _not_ staged changes; to see staged changes, you need to use `--cached`. This is especially weird when diffing between a fixed point (e.g. a commit hash) while going through the motions. If it's not clear why this would be weird, try out the following: * g…

Not to subtract from your point at all, but newer versions of Git allow you to use `--staged` as a synonym for `--cached`. That this is the default behaviour still makes no sense, but at least the name does.

That's good to know, but one has to wonder why that didn't change 15 years ago. It's representative of the general problem with Git: no particular problem with having bad UX for a long time without improving it. It seems like things started to get better in the last few years, but seriously it's not like the problems weren't obvious for a long time.

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

#92

Post by tomelliott »

smeenai wrote: post #55
sequoia wrote: 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…

Disclaimer: I work at Facebook. Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.

Pretty sure that isn’t true.

If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time.

Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one.

However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the company really committed to supporting open source projects. At that time it was more ‘if an individual engineer wanted to then go for it’ rather than there being any formal process or consideration of longer term commitments.

That changed fairly shortly afterwards with the creation of the OSS team.

I remember someone transitioning to the newly formed team and moving from Dublin to London to do so in ~2012, as we became housemates :)

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

#93

Post by koreth1 »

nailer wrote: post #23
justinsaccount wrote: post #14

Earlier quoted context omitted.

Does network effect even apply if it's compatible with existing git repositories?

Looking back when the last change happened: there was a subversion integration with git, but people actually switched to git for proper decentralised version control rather than use it. Then switched to GitHub to recentralise but that’s off topic.

I remember git-svn being pretty commonly used back in the day (circa 2007). At that point a lot of open-source projects were still using svn and if you wanted to use git locally, git-svn or something similar was how you did it.

My first experience with git was using git-svn to work with my company's internal svn repository, which I did for a couple years before the company stopped using svn. There was no internal desire for decentralized version control (rather the opposite, in fact; they wanted centralized permission management and such).

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

#96

Post by thijser »

durham_meta wrote: post #82

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

The GitHub repo says that Mononoke and EdenFS is "not yet supported publicly". The code seems to be all in the open source repository though, what does the "not supported" mean here?

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

#97

Post by durham_meta »

yewenjie wrote: post #89
durham_meta wrote: post #82

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

I believe at some point the GitHub project used to be called Eden, right? When was the name changed and why?

Good memory! Internally Eden eventually became synonymous with our virtual filesystem, so we decided it was better to choose a new name to avoid that confusion.

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

#98

Post by halter73 »

masklinn wrote: post #51
lijogdfljk wrote: post #31

Earlier quoted context omitted.

I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit. I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed. Stage + Unstaged is my working area, and the two live toge…

> Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to. You can just use the tip as your staging. Use interactive amending to move changes from the working copy to the commit, and when you want to "commit", finish up the message. hg actually has an "unamend" command (part of the "uncommit" standard extension) w…

`git reset HEAD~` doesn't feel like that much of a contortion to me. It's the destructive change that requires more contortion (`--hard`) which feels fair. Maybe this is stockholm syndrome though.

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

#99

Post by combyn8tor »

sequoia wrote: 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…

For me it was Parse.

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

#100

Post by ajkjk »

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.

I think a lot of people see this and think "I'm switching as soon as possible". It might be the 10x you need (although IMO 2x would do).

People are SUPER over dealing with using Git on large repos.

Post reply on HN