Sapling: A new source control system with Git-compatible client • Hacker News Board

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

#541

Post by codethief » Tue, Nov 22, 2022, 12:11 PM UTC

simplotek wrote: post #536

masklinn wrote: post #460

Earlier quoted context omitted.

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

> What's wrong with checking out a branch?

The fact, e.g., that it's a completely different operation than checking out a single file or folder? (One changes HEAD, one doesn't. One warns about overriding local changes, one doesn't, etc.)

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

#542

Post by Tomis02 » Tue, Nov 22, 2022, 12:56 PM UTC

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…

In case I wasn't clear, "git has an unintuitive and unfriendly CLI with bad defaults" when compared to hg.

Just compare the man pages! "git help clone" vs "hg help clone".

A random (trivial) example off the top of my head. When working with branches:

> git pull

> git switch another-branch

Your branch is behind 'origin/another-branch' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch)

... why? I literally just pulled, why are you asking me to pull again? 99% of the people on the planet literally want the last version of that branch (provided there's no local changes leading to a conflict).

Compare with hg:

> hg pull

> hg update another-branch

Done.

I haven't worked with hg in a long time so I can't really provide an "absolute best example". All I can say is that, from memory, hg always got out of the way, and when I wanted to do something out of the ordinary I could either guess how to do it or it was easy to figure out from the manual.

With git, almost nothing's easy. It can become easy if you invest a lot of time in understanding how it works internally (which explains some of its CLI choices). But that to me is a sign of a bad tool. "all obscure things are a quick googling away" - why expose the user to obscure things to begin with?

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

#543

Post by GoblinSlayer » Fri, Dec 02, 2022, 9:46 AM UTC

simplotek wrote: post #537

GoblinSlayer wrote: post #451

Earlier quoted context omitted.

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

I assume tfs and svn work with feature branches the same way. In my experience with feature branches in tfs they were a hindrance, not a win.

Local branches store immutable state, but shelves can be unpacked anywhere (like a stash), thus local changes carry over, but git deletes them on every occasion.