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

151–160 of 543 posts

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

#151

Post by mariusmg »

vfclists wrote: post #73
sequoia wrote: post #50

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…

If you think Facebook are bad when it comes to abandoning software projects, try Microsoft.

Still missing Clippy ?

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

#152

Post by andrewshadura »

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…

Consider also trying git-crecord, which is a port of he's curses-based partial commit interface.

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

#154

Post by IshKebab »

thijser wrote: post #71
msarnoff wrote: post #61

Command name conflicts with the `sl` utility that has existed for decades. https://github.com/mtoyoda/sl

"It's just a joke command, and not useful at all." with the last release 8 years ago. I understand that Meta didn't mind conflicting with that.

Doesn't matter. If anyone used a name at any point in time before you can never use it again. Apparently.

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

#155

Post by palisade5132 »

xctr94 wrote: post #105
vfclists wrote: post #73

Earlier quoted context omitted.

If you think Facebook are bad when it comes to abandoning software projects, try Microsoft.

Google isn’t far behind either. Perhaps corporate-owned open-source ecosystems weren’t a great idea.

I thought one of the main open-source's selling point is the fact you can fork it and maintain it even when the original author abandons it. Any alternative I can think of is a community-owned open-source, which probably wouldn't often work due to limited resources and no initial funding or a corporate-owned closed-source, which once abandoned is dead for good.

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

#156

Post by still_grokking »

thijser wrote: post #48
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 co…

Sounds like saying bye-bye to any meaningful history.

Rebasing, cheery-picking, or reverting of commits becomes impossible when every save of a file is pushed.

You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess).

Why not go one step farther: Just make an automatic block image of the whole systems of every developer machine every few seconds. You could than just deliver the image. No docker setup needed any more. Just write code. And when the local version works, ship the whole local system just as it is. ;-)

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

#157

Post by Shish2k »

noamelf wrote: post #94

Trying to use it on existing git repo doesn't work... At least not out of the box, I wonder why is that? Makes it less fun to work with as you can't easily switch

It needs its own client-side data, but it will work with existing git servers - so switching is as hard as running “(git|sl) clone https://github.com/…"

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

#158

Post by still_grokking »

ajkjk wrote: post #86
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.

Weird, it's one of my favorite changes. Finally I might get a version of Git which works without a bunch of extra crap getting in my way! you can always just use another commit as a staging area, I figure, and it'll make all the commands simpler and more intuitive so it wins in my book.

> you can always just use another commit as a staging area,

And than you have to do gymnastics with rebasing and rewriting history afterwards. Using the staging area upfront is much simpler!

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

#160

Post by jcranmer »

IshKebab wrote: post #150
masklinn wrote: post #49

Earlier quoted context omitted.

> Is it really that confusing for Git? Complete shit is what it is. It's awkward, messy, inconsistent, and hard to compose.

The CLI and nomenclature for the staging area (what should be called "draft commit") is awful, but the actual concept is very easy to understand. I seriously doubt anyone who uses a sane interface to Git (e.g. a GUI) has any trouble with clicking + to add changes to the draft commit before committing it. Most GUI tools let you automatically add all changes before committing anyway so you don't have to know anything a…

The main problem I have with the staging area is that it amounts to being something that's like a commit except for, you know, not actually being a commit, and therefore things that normally work on commits don't necessarily work on the staging area.

A better fix would be to make the staging area an actual commit, and then reframe everything as easy ways to edit the latest commit. (This meshes well with adding features like Mercurial's phases or changeset evolution that make commit editing somewhat safer).

Post reply on HN