Live data from Hacker News

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

engineering.fb.com

61–70 of 543 posts

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

#62
post #12

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

It's simply not necessary to have that feature. Sapling encourages regularly committing and amending commits rather than staging changes. It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).

How do you construct a commit, in order to commit regularly, without having a staging environment in which to compose that commit?

Is the branch-tip simply the staging area? What if you're only half-done with that final commit?

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

#63

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…

> git add -p allows me to add chunks easily and create commits

your workflow resembles mine so I'm in the obligation of mentioning https://github.com/jesseduffield/lazygit which allows you to stage individual lines among other features. https://www.youtube.com/watch?v=CPLdltN7wgE

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

#64
Neat! I hope this is a step in the right direction towards and not-so-bespoke SCM.

I do wonder:

1) How it handles large (binary) files. This is a major pain point when using git and even the standard solution (git-lfs) leaves *a lot* to be desired.

2) How does server hosting currently work? I didn’t see any mention and am assuming it’s not an option currently? (two dependencies of Sapling are currently closed source)

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

#65
post #43
post #20

I'm not interested in a simplification of git, sorry. Git's major value proposition is that they added moving parts until the system worked great . If you don't want named branches, staging, or any other piece of the ideology, then subversion is a fine choice. But most folks moved on from svn for reasons

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 support the same workflows equally well, then surely that concept was unnecessary. (Whether the staging area is actually better served by other concepts is a matter of judgment.)

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

#67
post #23

Earlier quoted context omitted.

Does network effect even apply if it's compatible with existing git repositories?

Looking back when the last change happened: there was a subversion integration with git, but people actually switched to git for proper decentralised version control rather than use it. Then switched to GitHub to recentralise but that’s off topic.

Not everything that uses GitHub/BitBucket/GitLab etc. is (re)centralized. You can have an internal company hosting service and a public hosting solution, for example. I've also used the decentralized capabilities to synchronize between two computers.

There are many reasons why GitHub (or something like it) are popular, such as:

1) not having to host the infrastructure yourself (incl. hosting it on AWS/Azure/etc.)

2) discoverability -- being able to follow people/organizations creating projects you are interested in; being able to search for projects ~ having these on various websites makes it harder to discover them

3) additional functionality/capabilities like static web page hosting (great for things like personal projects), and CI/CD workflows

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

#68
post #65
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…

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-poor place to make good decisions.

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.

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

#69

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…

https://sapling-scm.com/docs/introduction/differences-git#sa... says: "If you want to commit/amend just part of your changes you can use commit/amend -i to interactively choose which changes to commit/amend. Alternatively, you can simulate a staging area by making a temporary commit and amending to it as if it was the staging area, then use fold to collapse it into the real commit."

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

#70
post #58
post #24

Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions. Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases…

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.

Post reply on HN