Sapling: A new source control system with Git-compatible client
61–70 of 543 posts
Re: Sapling: A new source control system with Git-compatible client
#62What 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).
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
#63I 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…
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
#64I 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
#65I'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…
Re: Sapling: A new source control system with Git-compatible client
#66The utility should obviously be called `sap' and not `sl'.
Re: Sapling: A new source control system with Git-compatible client
#67Earlier 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.
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
#68Earlier 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…
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
#69I 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…
Re: Sapling: A new source control system with Git-compatible client
#70Not 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…
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.