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

31–40 of 543 posts

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

#31

Post by lijogdfljk »

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 agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit.

I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed.

Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.

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

#32

Post by indymike »

softwaredoug wrote: post #22

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…

I remember when git was new, and the subversion crowd didn't jump on. Same discussion, different subjects. Git is/was awesome... but there is certainly room for improvement.

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

#33

Post by itslennysfault »

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.

Somehow that doesn't matter for FB. Yarn is not 10x better than NPM and it took off. React is.... ugh... React and it took over the whole dang industry.

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

#34

Post by saghm »

arxanas wrote: post #18
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 has an interactive commit staging command which accomplishes the same thing. In that case, it unifies the staging area with regular commits, which means you can also manipulate them the same way as regular commits. AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably…

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:

* get the hash of the HEAD commit * run `git diff ` and see that there are no changes * make some change to a file * run `git diff ` again and see the change you made * stage the change with `git add` * run `git diff ` again and no changes are show! * commit the change * run `git diff ` again and the changes are back

It's super bizarre to me that there would be some sort of intermediate state where changes aren't visible. I feel like it would make more sense to have some sort of formatting difference indicating unstaged versus staged but not committed versus committed, but I imagine changing that now would break all sorts of scripts, so we're stuck with it.

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

#35

Post by arxanas »

lijogdfljk wrote: post #31
mitrandir77 wrote: post #19

Earlier quoted context omitted.

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 agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit. I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed. Stage + Unstaged is my working area, and the two live toge…

In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).

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

#36

Post by yumraj »

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.

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

#37

Post by ArchOversight »

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 commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits.

Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the "whole" vs a patch that is more localized.

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

#39

Post by ArchOversight »

davidpfarrell wrote: post #25

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

This would break the workflow of using the staging area to break a larger change into smaller commits.

git add -p

Allows you to select hunks of changes and stage them for committing...

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

#40

Post by sdiacom »

saghm wrote: post #34
arxanas wrote: post #18

Earlier quoted context omitted.

It has an interactive commit staging command which accomplishes the same thing. In that case, it unifies the staging area with regular commits, which means you can also manipulate them the same way as regular commits. AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably…

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.
Post reply on HN