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

21–30 of 543 posts

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

#21

Post by ripa »

mitrandir77 wrote: post #19
ripa wrote: 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).

I guess each to their own. I want to stage my commit with regular commands, and then have the staging area work with (diff, add/remove etc).

I don't care for an interactive tool, IMHO I prefer using commands that are repeatable and learnable instead of stepping through some interactive workflow all the time.

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

#22

Post by softwaredoug »

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 as much a social problem around conventions, and lack of opinions in the tool itself, then anything about the underlying technology (which is rock solid IMO)

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

#23

Post by nailer »

justinsaccount wrote: post #14
nailer wrote: post #9

This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.

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.

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

#24

Post by fhd2 »

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 (like me). But I'm still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.

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

#25

Post by davidpfarrell »

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

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

#26

Post by jedberg »

In the argument of monorepo vs not, the usual argument goes like this:

- It's too hard to scale for a large monorepo!

- Google does it just fine!

- But I don't have access to Google's tools!

So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.

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

#27

Post by arxanas »

To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless. Then, you can use your usual staging workflows if desired, or use regular Git commands directly.

Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?

Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.

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

#28

Post by somnium_sn »

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 actually removing workflows (they are just different).

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

#29

Post by softjobs »

noahchumsky wrote: post #11
nailer wrote: post #9

This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.

You may find https://pijul.org/ interesting.

And https://github.com/martinvonz/jj.
Post reply on HN