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

531–540 of 543 posts

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

#531

Post by stevage »

bergheim wrote: post #527
stevage wrote: post #87

Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…

Admittedly this might not help since it is not CLI, but spend some time this weekend with Emacs and magit. You don't have to use emacs for anything else, just the magit client. It will transform your git experience.

I did something similar for years with Sublime and Gitsavvy. But I couldn't stop Sublime updating itself from time to time, and it kept breaking Gitsavvy, and it got really tedious to try to fix it.

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

#532

Post by stevage »

jakear wrote: post #198
stevage wrote: post #87

Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)

I used to use Gitsavvy in Sublime, and honestly it was much, much better than what VSCode offers so far.

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

#533

Post by achsvg »

durham_meta wrote: post #438
bentcorner wrote: post #417

Earlier quoted context omitted.

Just to clarify, I meant that I've already cloned it via git. Can I just start using sapling with it or do I need to delete the local repo and re-clone it with sapling?

You cannot just start using sl in a git repo. You need to make a Sapling clone of it. But you can make a Sapling clone of your local git repository, so you don't have to clone from the server again and you would get all your local work from your git repo. That might be the easiest way to try Sapling, so you don't have to delete your git checkout at all.

What's the command in sl to clone a local git repo? The documentation does not say anything about it...

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

#534

Post by int_19h »

juped wrote: post #323
indymike wrote: post #32

Earlier quoted context omitted.

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.

Subversion? You mean that unimpressive flash-in-the-pan CVS clone?

As I recall, the Big Deal with CVS-to-SVN migration was that many teams learned to creatively exploit the fact that CVS does versioning on a file-by-file basis. As late as 2008, I had to work in an environment where checking out different versions for different parts of the company's CVS monorepo was required to get anything to build.

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

#535

Post by simplotek »

Tomis02 wrote: post #486
Varriount wrote: post #406

Earlier quoted context omitted.

Can you elucidate? What did you find appealing/unappealing?

In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults. I want my VCS to be quiet, out of sight and do as it's told, because my main focus should be programming, not how to tame a tool that's supposed to save text. The fact that you have to "learn git", and that there are so many StackOverflow git question on how to do (what should be) trivial operations is probably a hint that things aren't great…

> In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults.

I see this claim often, but it never is accompanied by evidence or any concrete example.

I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away.

Do you actually have any concrete example to back your claims? What's the absolute best example you can come up with of said unintuitiveness and unfriendliness?

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

#536

Post by simplotek »

masklinn wrote: post #460
Varriount wrote: post #406

Earlier quoted context omitted.

Can you elucidate? What did you find appealing/unappealing?

> What did you find appealing/unappealing? The entire CLI is badly designed, with highly non-orthogonal commands interacting in unexpected ways. Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development Git also diverged significantly from the SVN command line, but instead of following the tasteful Darcs path of making commands clearer a…

> Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development

Isn't git switch syntactic sugar for git checkout? What's wrong with checking out a branch?

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

#537

Post by simplotek »

GoblinSlayer wrote: post #451
Varriount wrote: post #406

Earlier quoted context omitted.

Can you elucidate? What did you find appealing/unappealing?

If you're interested, can compare tfs to git. Maybe it's ide integration quality, but FWIW: 1) tfs: shelves are named and can be worked with independently; git: stashes are numbered in a sort of a stack and only the top stash is unpacked and deleted destroying your data, infuriating, also local edits are moved into the stash, not copied. 2) tfs: branches are mapped to different folders and can be worked on simultaneo…

> 1) tfs: shelves are named and can be worked with independently; git: stashes (...)

I don't think your comparison makes sense. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. You use local branches to track independent work.

> tfs: can't commit unresolved merge conflicts; git: commits just fine

Again, this doesn't make sense. In git, users determine whether a conflict is resolved or not. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.

> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.

Honestly I didn't understood what point you tried to make. Merge conflicts happen because multiple sources of change touch the same document region in a way that can't be resolved automatically, thus needing human intervention. To the best of my knowledge, there is no cvs in the world that eliminates merge conflicts.

Regarding Git's support for feature branches, the fact that you don't understand the big win Git brought to the world with it's branching model is already a testament to how groundbreaking Git was at the time, and how everyone around was quick to roll out Git clones that follow the same approach. To see what I mean, spend a day working with a SVN repository trying to do work involving feature branches.

> git: if something happens to the branch label, the commits are gone.

Aren't you actually saying that if you delete a branch then the branch is deleted?

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

#538

Post by CRConrad »

josephg wrote: post #496
CRConrad wrote: post #492

Earlier quoted context omitted.

> Because motivated, high performing people need to have control over their own destiny. I don't quite buy this: Those same "motivated, high performing people" don't seem to have anywhere near the same "need to have control over their own destiny" when it comes to the commercial closed-source tools they use.

Really? I’ve seen people reinvent the wheel all over the place because their tools weren’t quite working for them. This instinct is the reason most good software has APIs - so you don’t have to ditch the tool entirely to customise it to your workflow. And most medium to large companies have all sorts of wacky customisations on top of existing software. Eg perforce at Google. Well, everything at Google. And a friend a…

IME there's at most one of those wheel-reinventors for each zillion devs unthinkingly swallowing whatever (VSC) Microsoft is spurting down their throats this week.

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

#539

Post by sicariusnoctis »

durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

For a given repository, is it possible to have multiple worktrees for different "branches"? (Just like git worktree.)

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

#540

Post by codethief »

simplotek wrote: post #535
Tomis02 wrote: post #486

Earlier quoted context omitted.

In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults. I want my VCS to be quiet, out of sight and do as it's told, because my main focus should be programming, not how to tame a tool that's supposed to save text. The fact that you have to "learn git", and that there are so many StackOverflow git question on how to do (what should be) trivial operations is probably a hint that things aren't great…

> In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults. I see this claim often, but it never is accompanied by evidence or any concrete example. I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away. Do you actually have any concrete example to back you…

> I see this claim often, but it never is accompanied by evidence or any concrete example.

We've had dozens of discussions about this here on HN – with lots of evidence and concrete examples.

https://www.google.com/search?q=git+user+experience+site%3An...

Post reply on HN