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

171–180 of 543 posts

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

#171

Post by IshKebab »

somnium_sn wrote: post #28
ripa wrote: post #12

What is the argument against having a staging area? The Git staging area is crucial in my mind.

It stems from the original Mercurial implementation. The goal here is that every operation leaves the repository in a good state that can be pushed/pulled. That's why Mercurial and Sapling rely on commit/amend/uncommit, etc and for example usually discourage the use of interactive rebasing in favor of restack and other operations that add another "state". It facilitates the mental model for developers without actuall…

As I understand it restacking is rebasing no?

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

#172

Post by jcranmer »

halter73 wrote: post #98
masklinn wrote: post #51

Earlier quoted context omitted.

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

The way I think of it, there's basically three copies of the file in play: in HEAD, in staging area, and on disk. I cannot trust my memory to remember which variant of "git reset" copies the file in HEAD to the staging area, which variant copies staging area to disk, and which variant copies HEAD to disk (in all cases, the third copy remains uninvolved). Getting it wrong potentially creates unrecoverable data loss. And, unfortunately, this is one of those cases where reading git's documentation is less than helpful.

Combine this with the case where "I want to break one commit into two commits," where now I have to worry about making sure I know if the command is going to change the revision HEAD points to. At least there, the old commit will still exist as backup in the invariable scenario I screw something up.

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

#173

Post by IshKebab »

elischleifer wrote: post #5

the number of projects that require the scaling factor of something like this is very small. git with lfs scales very well for most repositories. That said the actual flow of git is pretty raw. There are other pretty solid projects out there that support undo commands into git. Stacked PRs are a blessing and a curse - still not convinced they are the correct way to build software as a team.

Public projects, sure. But plenty of companies have very large codebases that would benefit from this. Even if Git can handle it it can get very slow with largish repos.

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

#174

Post by Agingcoder »

loudmax wrote: post #70
bogwog wrote: 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…

Fortunately, zstd seems to be in active development: https://github.com/facebook/zstd As far as I can tell, most of zstd's development is still by Facebook employees, though not all of it. I tend to think zstd has enough traction that development would continue even if FB were to abandon the project.

I think zstd is originally not a Facebook project. https://fastcompression.blogspot.com/2015/01/zstd-stronger-c...

I believe Yann Collet, author of lz4, eventually went on to work for Facebook and finished it there.

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

#176

Post by still_grokking »

jcranmer wrote: post #160
IshKebab wrote: post #150

Earlier quoted context omitted.

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…

The main problem I have with the staging area is that it amounts to being something that's like a commit except for, you know, not actually being a commit, and therefore things that normally work on commits don't necessarily work on the staging area. A better fix would be to make the staging area an actual commit, and then reframe everything as easy ways to edit the latest commit. (This meshes well with adding featur…

A "draft commit" (I really like that name!) is not a commit, and should not be handled as such. This would make this feature more or less useless.

The whole point of the "draft commit" is that you can easily see changes against your (uncommited!) changes. That helps to build up a commit step by step.

Committing WIP stuff (and maybe even pushing that) makes the history useless. Branches don't help as you end up with millions of WIP branches that are all incompatible to each other (and the evolution that happened elsewhere). Only keeping WIP branches up to date is a full time job than.

Git has already a means to edit the latest commit easily: `git commit --amend`.

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

#178

Post by tikhonj »

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…

I dunno, there's a lot of value in having a tool that's flexible and lets you work the way you want—even if that fundamentally means there is no one blessed way to do things.

Git has a lot of incidental complexity and unforced design problems, but the fact that it's inherently flexible is not one.

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

#179

Post by alwillis »

oorza wrote: post #127
jcranmer wrote: post #116

Earlier quoted context omitted.

Mercurial revsets and phases are two killer features of mercurial that blows any counterpart git has out of the water. Phases are a property of revisions that essentially let you know their state. By default, there are three phases: public, draft, and secret. You can't rebase a public revision, nor can you have a public revision with a secret parent. So you get out of this concept things like safe rebasing, or barrie…

Why do you want to? Not trying to be snarky, but I've been using various source control tools for closer to 20 years than 10 and I can't remember when I've ever needed or would have benefited from revsets. I'm genuinely curious what problem this solves and whether I've just never experienced or have made my own hodge podge solution for it incidentally.

No disrespect but you’re kidding, right?

We often (a.k.a. constantly) want to see a subset of commits that meet some criteria.

The way Git handles this is by adding more flags, which doesn’t scale.

Just look at the man page for git log… it’s nuts.

Having a concise functional query language [1] is one of Mercurial’s and I guess Sapling’s killer features.

[1]: https://hg.mozilla.org/mozilla-central/help/revsets

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

#180

Post by optymizer »

dkasper wrote: post #30

As a Meta employee for almost 4 years what I will say is I was skeptical at first coming from git, but the sapling system works very well in practice in my experience. I still use git for everything outside of work, but I may consider sapling now.

Can confirm. I like sapling better than git. Who needs branches? Why stress about detached heads? Working with a stack of commits is a breeze too.

absorb split histedit uncommit unamend revert metaedit

Once you use them, it's hard to go back.

Post reply on HN