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

311–320 of 543 posts

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

#311

Post by alwillis »

1attice wrote: post #302
alwillis wrote: post #219

Earlier quoted context omitted.

On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git. Outside of the Git fanboy bubble, developers don’t want to have to be version control experts, which once you get past a certain level of Git usage, you have to be, whether you wanted to or not. Especially if your team doesn’t have that person…

To be fair, if I had a junior dev who couldn't skim a man page of 19 000 words, I would have freestanding concerns about their ability to contribute -- being able to inhale knowledge is a core competency of any engineer. That said, I hear you when you say that most folks (think) they have better uses of their attention. I daresay they're wrong, but it's not my place to dictate terms to anyone's curiosity, my own incl…

Agreed.

It wouldn’t be that big a deal except pretty much every important git command is similarly complex for noobies.

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

#312

Post by djur »

otikik wrote: post #202
waynesonfire wrote: post #109

Earlier quoted context omitted.

Quoted post unavailable.

GitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.

I don't think this is true. GitHub (the website) became very successful with virtually no feature overlap with the git CLI. I suppose you could say that GitHub pull requests and forks are a replacement for git's built-in email-based workflow, but that's not really what people complain about when they say git is hard to use (and it's not like the other DVCSes had obviously better solutions).

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

#313

Post by matheusmoreira »

josephg wrote: post #306
matheusmoreira wrote: post #292

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

Does it have to be so disrespectful, though? Demanding things, getting frustrated when denied and ghosting the original project to the point even they are surprised when a fork shows up?

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

#314

Post by acchow »

michaelmior wrote: post #252
mikepurvis wrote: post #114

Earlier quoted context omitted.

My brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard ", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh. So yes, in short I agree.

git reset HEAD@{1} should do the trick to "uncommit" and keep uncommitted changes in the absence of conflicts. (I may be missing some edge cases.) It does however unstage changes.

Right, if you grok the git model then this makes sense. But if you just want to use a tool without learning how it manages state, git is a pain.

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

#315

Post by pianoben »

jupp0r wrote: post #285
jedberg wrote: post #26

In the argument of monorepo vs not, the usual argument goes like this: - It's too hard to scale for a large monorepo! - Google does it just fine! - But I don't have access to Google's tools! So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them wer…

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.

Or, they run in to limits with Github and mistake them for git limitations...

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

#316

Post by eesmith »

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.

I learned cvs, sccs, svn, bzr, hg, and git, in that order. I still find git confusing, and stick with Mercurial whenever possible.

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

#317

Post by saghm »

still_grokking wrote: post #144
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…

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 lot of mistakes on the way to learning how to use it properly.

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

#318

Post by masklinn »

IshKebab wrote: post #150
masklinn wrote: post #49

Earlier quoted context omitted.

> Is it really that confusing for Git? Complete shit is what it is. It's awkward, messy, inconsistent, and hard to compose.

The CLI and nomenclature for the staging area (what should be called "draft commit") is awful, but the actual concept is very easy to understand. I seriously doubt anyone who uses a sane interface to Git (e.g. a GUI) has any trouble with clicking + to add changes to the draft commit before committing it. Most GUI tools let you automatically add all changes before committing anyway so you don't have to know anything a…

What are you talking about? My comment is about gitrevisions(7).

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

#319

Post by dastbe »

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.

can you speak to commit throughput of the sapling server? While there's tooling to make git scale better (like sparse checkouts) scaling commit throughput for automation is a pain.

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

#320

Post by charcircuit »

arxanas wrote: post #41
ArchOversight wrote: post #37

I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and making commits as I go along doesn't work well. How does sapling let me take a long list of commits and break them into larger but more manageable chunks? git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a comm…

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which…

sl record is another shorthand for an interactive commit.
Post reply on HN