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

221–230 of 543 posts

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

#221

Post by johannes1234321 »

sixstringtheory wrote: post #199
Shish2k wrote: post #192

Earlier quoted context omitted.

Nothing is perfect, but some things are clearly better than others - hence why we’re nearly-all using git rather than "learning and familiarising ourselves" with CVS :)

Fair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git. I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot. And I guess it bears repeating that I’m interested in possibility and…

> where I haven’t thought of a way to do it with Git.

With git one can do "everything" true, doesn't mean that I want to teach everybody first what a DAG is and how one can manipulate that using git commands, but want to have something simpler. And yeah, git became a lot better over the years, but the plumbing still shines through in many places with inconsistencies.

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

#222

Post by fragmede »

arxanas wrote: post #65
1attice wrote: post #43

Earlier quoted context omitted.

Despite the greytexting of this comment, I'm still really interested in the discussion around it -- and I'm really curious to hear from people that have the opposite experience. Moving from SVN to git felt like liberation because there were suddenly idiomatic ways of expressing states that were sort of smushed together by SVN -- stuff like, "I have some changes in my branch I want to line up for commit" which, became…

In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not having them, but Git would have been better off if they consolidated into a single idea and concentrated their efforts on that. If you can remove a concept from Git and still suppor…

coming from SVN, the biggest thing about is it's distributed nature making everything local and fast. yeah there are a lot of other concepts along with that too, but just being able to work on my laptop, commiting and making branches to my heart's content, without talking to a server until I'm ready for that step was the killer feature for me.

SVN branches were this doofy copy procedure that made sense once you drank the Kool aid, but they were so unwieldy compared to git

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

#225

Post by arxanas »

martinvonz wrote: post #204
kbd wrote: post #122

Earlier quoted context omitted.

I'm glad you mentioned Jujutsu. Given that it's also a git-compatible SCM my first thought upon seeing this post was how Sapling and Jujutsu compare.

I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy. Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We'r…

Yep — after trying out Sapling, it aborts many operations due to working copy changes, which I now find to be jarring interruptions to my workflow. Jujutsu (and even git-branchless) have much better support for juggling working copy changes, which is invaluable in a patch-stack workflow.

The Sapling support for remote repositories was a little rough in my opinion. Jujutsu and git-branchless can both co-locate with the Git repository, so you can always drop down to Git commands if there's something you're having trouble doing. (I find the `jj git` commands to also be better at interacting with remotes for now.)

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

#226

Post by joshuamorton »

still_grokking wrote: post #156
thijser wrote: post #48

Earlier quoted context omitted.

It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. We develop HighFlux[1] which also gets rid of the staging area. It simplifies your mental model of what's going on a lot. Because everything you save is automatically committed, switching to a different task/branch is also always instant without needing stash. Because what you're testing locally is what you're co…

Sounds like saying bye-bye to any meaningful history. Rebasing, cheery-picking, or reverting of commits becomes impossible when every save of a file is pushed. You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Why not go one step farther: Just make an automatic block image of the whole systems of…

> You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess).

Google does this, it has saved my butt on more than one occasion.

> Sounds like saying bye-bye to any meaningful history.

I'm so confused, you just amend the most recent commit, or work with changes unstaged and uncommited. Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working on the next thing, either back to HEAD if its unrelated, or on top of the just-pushed changes if it depends on them.

It's vastly simpler than having to git add at random times.

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

#227

Post by chaxor »

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.

It's a part of the Linux kernel now, so I think it's pretty safe

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

#228

Post by jakear »

zabzonk wrote: post #209
jakear wrote: post #198

Earlier quoted context omitted.

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)

because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach

You still gotta type the message.
Post reply on HN