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

141–150 of 543 posts

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

#141

Post by mitrandir77 »

eisbaw wrote: post #54

Major pain point of monorepos: Merge-conflicts. When a merge-conflict happens YOU need to be expert and resolve all conflicts the right way, across the many unrelated domains mixed together. How does sapling solve that? It can't... IMHO Sapling looks like "Git for dummies". And Git teaches some pretty useful concepts, which are worth it.

I don't see why merge conflicts would be a pain specific to monorepos. The merge conflict arises when you and some other person modify the same parts of the same file. No matter the repo size the correct solution here is figuring out the intention of the other person by reading their change or talking to them and deciding how to combine it with your change.

The only reason which may make merge conflicts happen slightly more often in monorepo (vs constellation of small repos) is that not having the repo cloned locally is an obstacle to make the change. So some folks won't bother contributing repo that they'd have to clone first and instead they'd file a bug to the owners.

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

#142

Post by Shish2k »

feep wrote: post #10
Shish2k wrote: post #8

I’ve been using FB’s mercurial fork for years, wishing for all that time that I could have the joy of the fb-hg CLI while remaining compatible with github because that’s where 99+% of the code lives - from my brief experimentation, sapling appears to be that. I look forward to never using the git CLI again :D

I felt the same joy on reading the overview. Cleans up the git workflow so nicely. ...until I got to pull requests (Granted, that is github, not git). But it looks like you cannot generate a standard pull request with it. https://sapling-scm.com/docs/git/intro#pull-requests Haven’t tried it yet, looking forward to it.

I actually just created my first PR from a sapling repo now - not sure why it’s not documented, but you can push your local development branch to a remote server, and in the case of github, you even get the “it looks like you’ve just pushed a local branch, would you like to turn this branch into a PR?” prompt, and it appears indistinguishable from a branch created with the Git CLI.

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

#143

Post by mikepurvis »

mjsir911 wrote: post #130
stevage wrote: post #87

Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…

Maybe I'm misunderstanding, but isn't this what `git revert` is for? Harder with an amend due to having to get the difference of commits within the reflog, sure.

git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.

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

#144

Post by still_grokking »

saghm wrote: post #34
arxanas wrote: post #18

Earlier quoted context omitted.

It has an interactive commit staging command which accomplishes the same thing. In that case, it unifies the staging area with regular commits, which means you can also manipulate them the same way as regular commits. AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably…

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

Think for example about something like: You use some tool to do some automatic changes. This creates hundreds of changed files. But the result isn't working. You could commit that, sure. But than you would need to rewrite history before pushing because creating not working commits is a terrible idea. Or you could just stage the changes for now. Than you can change / repair the still missing parts. Git diff will helpfully show you only the new changes but ignore the staged stuff as long as it's untouched. You would now for example easily see changes that you made to the automatic rewrites. Without the staging behavior you could only compare with a committed state, and drown in hundreds of changes that are unrelated.

The main problem with the staging area is that quite some GUI tools don't use it correctly. The tools try to "simplify" Git by ignoring how the stating area is supposed to work, or ignore it completely like the infamous JetBrains IDEs. (IDEA is the tool that needed almost 10 years to implement Git sub-modules…). I think the VCS handling in IDEA is on the surface very polished. But when it comes to something like the staging area the UI-wise very crappy VS Code Git support beats that by far. Sublime Merge does also the "right thing"™ and hides the staged changes at the bottom so you see only the the changes to the changes. Exactly as the staging area is meant to be used!

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

#145

Post by durham_meta »

jcranmer wrote: post #134
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.

Is it possible to use git commands on an sl checked out repository, or vice versa? Or at least get something close enough to a git repository that I could run git commands on it, so I can fake it for internal tooling?

Unfortunately you can't run git commands directly right now, since there is no .git directory at the root of the repo. Under the hood there is a .git directory hidden away somewhere under the .sl directory, but we consider that an implementation detail and are likely to change how we store the actual git data in the future. So we don't support people running git commands in there.

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

#146

Post by terminal_d »

stevage wrote: post #87

Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…

Emacs + Magit, and never looked back.

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

#147

Post by pooper »

mikepurvis wrote: post #143
mjsir911 wrote: post #130

Earlier quoted context omitted.

Maybe I'm misunderstanding, but isn't this what `git revert` is for? Harder with an amend due to having to get the difference of commits within the reflog, sure.

git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.

I don't know much about git but I just do

    git reset --soft HEAD~n
where n is the number of commits I want to undo.

Known issue: can't undo all the commits.

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

#148

Post by ravi-delia »

layer8 wrote: post #125
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 disagreed with the things that made Facebook fork off in the first place. Could you elaborate on what these things are and why you disagree with them?

Presumably the things listed in the second paragraph (Phabricator, node hashes)

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

#149

Post by mitrandir77 »

IshKebab wrote: post #137
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 was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.

https://news.ycombinator.com/item?id=33615077

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

#150

Post by IshKebab »

masklinn wrote: post #49
chungy wrote: post #17

Earlier quoted context omitted.

Is it really that confusing for Git? I had basically that entire manpage memorized early on (even before the manpage existed....)

> 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 about it if you don't want to.

They just needed to name things better (what is a "soft reset" again?).

Post reply on HN