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

41–50 of 543 posts

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

#41

Post by arxanas »

ArchOversight wrote: post #37

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…

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning).

To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).

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

#42

Post by saghm »

sdiacom wrote: post #40
saghm wrote: post #34

Earlier quoted context omitted.

My favorite example of the staging area being super weird is `git diff` behavior. By default, git diff will show unstaged changes as well as committed changes, but _not_ staged changes; to see staged changes, you need to use `--cached`. This is especially weird when diffing between a fixed point (e.g. a commit hash) while going through the motions. If it's not clear why this would be weird, try out the following: * g…

Not to subtract from your point at all, but newer versions of Git allow you to use `--staged` as a synonym for `--cached`. That this is the default behaviour still makes no sense, but at least the name does.

Ah, that is a better name! I'll have to add that to my mental list of git UX improvements (I'm also a big proponent of `git switch`)

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

#43

Post by 1attice »

1attice wrote: 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 the handy one-word concept, "staging".

The before-times were marked by a lack of these fine distinctions. While they existed in fact, they were obscured in-system.

Like a map, any tool should 'resemble' the sphere of human activity it potentiates, and git resembles our diverse workflows better because it has so many asinine distinctions.

This was always its strength, and indeed, likely the reason the platform is called 'git' in the first place, as 'smarmy git' (English idiom for 'smartass') implies an insufferable drawer-of-distinctions.

And like a smarmy git, it's easier to complain about git than it is to replace it.

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

#44

Post by ak67 »

yumraj wrote: post #36

I find it interesting that this is open sourced a few days after 11K were laid off. Was bulk of the team behind this laid off wherein it made sense to open source it to involve the community to take it forward rather than paid resources? To be clear: I'm NOT criticizing them open sourcing this.

The open sourcing schedule was completely unrelated to the layoffs.

The team working on Sapling has been planning this release for a very long time and will continue working on Sapling to support our internal engineering efforts.

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

#45

Post by boberoni »

yumraj wrote: post #36

I find it interesting that this is open sourced a few days after 11K were laid off. Was bulk of the team behind this laid off wherein it made sense to open source it to involve the community to take it forward rather than paid resources? To be clear: I'm NOT criticizing them open sourcing this.

I doubt that the FB people involved with the layoffs are the same FB people who decided to open source the Sapling project. Many FB engineering managers were not aware that the layoffs were being planned. Moreover, it takes up-front planning and design decisions (by more than just a few days) for a private company to open source their internal projects.

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

#46

Post by quark12 »

masklinn wrote: post #15
chungy wrote: post #13

> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.

Meh. If it has mercurial's revsets instead of gitrevisions(7) I'm game, I'll happily give up the staging if I don't need to open that manpage ever again. edit: yep, so long git check if a given commit is included in a bookmarked release: sl log -r "a21ccf and ancestor(release_1.9)"

You can also do `sl/hg log -Gr a21ccf+release_1.9`. The graph tells you the relation of selected commits. Last time I checked, git does not have the same --graph rendering yet - it only considers direct parents not ancestors.

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

#47

Post by ArchOversight »

arxanas wrote: post #41
ArchOversight wrote: post #37

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…

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which…

If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke.

It sounds like I would need to:

- switch - amend the commit - restack? - switch back to the HEAD?

Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sapling-scm.com/docs/commands/fold

This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.

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

#48

Post by thijser »

chungy wrote: post #13

> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.

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 committing, I also never have CI failures anymore (with the staging area I frequently had unexpected interactions with unstaged changes and sometimes even accidentally forgotten added files).

1: https://highflux.io/

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

#49

Post by masklinn »

chungy wrote: post #17
masklinn wrote: post #15

Earlier quoted context omitted.

Meh. If it has mercurial's revsets instead of gitrevisions(7) I'm game, I'll happily give up the staging if I don't need to open that manpage ever again. edit: yep, so long git check if a given commit is included in a bookmarked release: sl log -r "a21ccf and ancestor(release_1.9)"

Is it really that confusing for Git? I had basically that entire manpage memorized early on (even before the manpage existed....)

> Is it really that confusing for Git?

Complete shit is what it is.

It's awkward, messy, inconsistent, and hard to compose.

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

#50

Post by sequoia »

Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware.

Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware.

EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it works pretty well all things considered and Facebook has continued to support and evolve it over time!

For all I know Sapling is fantastic and will be developed for years to come. But personally I can't help but feel "once burnt, twice shy" (or in this case, twice burnt once shy). I'd be happy to be wrong here because ergonomics of Git are really frustrating in many places.

0: https://www.phacility.com/phabricator/ 1: https://flow.org/

Post reply on HN