Live data from Hacker News

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

engineering.fb.com

301–310 of 543 posts

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

#301
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

Wait—there’s a FB fork of Mercurial? Would love to know more about it!

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

#302
post #68

Earlier quoted context omitted.

Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-…

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 included!

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

#303

Stack of commits seems to be similar to what one would call a patch queue if one is using Git. The fact that they have concepts like unamend suggests that they have thought about this in a way more turtles all the way down way than the Git designers. A versioning for your history changes—why, of course.

The fact that they have concepts like unamend suggests that they have thought about this in a way more turtles all the way down way than the Git designers.

You can thank the Mercurial developers for these concepts.

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

#304

> There is no staging area. I don't actually want "No" staging area. What I want is, once I "add" something, the file stays added. Currently, I have `git st` alias setup : st = !git add -u && git status This auto-updates the staging area for files that were previously staged. So I get `git add` but also don't have to re-add anything manually from there ... Since I do `git st` quite frequently, this works out for me .…

That seems like the worst possible use of the staging there is, it creates overhead and complicates diffing for no value whatsoever. If you want that behaviour, you can just `git commit -a` when you create your commit, then you only have to "git add" brand new unknown files.

Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging, and `git commit -a` is basically an equivalent of having no staging.

The reasons for that are:

1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.

2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.

3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.

So I kinda get why GP wants what he wants. This isn't crazy.

Now, that being said, I personally have absolutely no problems with how git does that now: I've figured out a workflow that solves these problems for me, and everything is ok now. This workflow is basically making many dozens of tiny commits to a branch without even bothering to name them properly, and then just doing `git rebase -i` many-many times while working on a single branch. So I just commit the code I don't intend to keep with a label "drop that", and drop these commits when I'm done. And other commits usually are heavily reordered and squashed into 3-5 larger commits that make some sense on a higher level (like 500 LOC of refactoring first, and then 1 LOC of an actual bug-fix, which usually makes much more sense than just 500 LOC of a bugfix, that solve the problem somehow, but it's absolutely not obvious how exactly). I rarely can figure out that separation before I'm done. In fact, I often fix the problem first, then refactor, then roll-back the fix just to add it again in a separate commit in the end (if the refactoring and the fix affect the same file, which also is often the case).

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

#305

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD.…

[deleted]

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

#306

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…

> 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. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.

This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.

The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.

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

#307
post #258
post #228

Earlier quoted context omitted.

You still gotta type the message.

I think the original poster was referring to staging the commit as their "thinking" step, not composing the message. Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away. I think your workflow would work well if you see commits as "development…

For what it's worth, you can do similar to "add -p" in VSC by using "Next Change" to scroll through a file in the diff view and adding hunks with individually with "Stage Selected Ranges".

It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.

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

#308
post #198
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…

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)

Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.

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

#309

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…

Fossil is a pretty great alternative to git.

https://www.fossil-scm.org/home/doc/trunk/www/index.wiki

Post reply on HN