[deckard1]

that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained.

Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every command was backed by some horrible O(n^2) operation or really slow network connection.

git isn't hard. FFS, we shouldn't keep seeing these posts hitting HN every week. iptables? That's tough. DNS? No thanks. Managing package.json and keeping an app up-to-date? Git is nothing in comparison to the real challenges I face everyday.

[recursive]

I've been using the staging area for a long time. It only makes me wish I could turn it off.

[gmueckl]

git is FUCKING HARD due to its tons of poorly designed misfeatures. The index/cache/staging area is the worst of them. If git wants to make any progress towards actual usability, this mess needs to be untangled with prejudice.

Other tools have none of this overly stateful bullshit. When I want a file to be included in the next commit, I don't want a silent, implicit copy to be whisked away into some interal storage the moment I flag it. There is NO reason why merges need to destroy the contents of that same storage area. The totally confusing semantics of the reset command with the three nonsensically named modes soft, mixed and hard are also created solely by this particular misfeature of a magical hidden storage area.

There is also no reason to even support destructive history editing. Immutable history is the correct choice. The mercurial evolve extension, for example, supports rebasing without destroying history.

Also, the combination of not being able to close branches instead of deleting them and not storing branch names in commits makes git history completely undecipherable when you have to go back more than a few merges. You might just as well throw it into the garbage bin.

Just take a look at competing tools (free and commercial) to see what's being innovated in this space and how this widespread obsession with git is in fact preventing much needed progress.

[jatone]

tl;dr; a monkey is given a hammer and is baffled by utility.

rofl. git is perfectly usable. proven by the hundreds of thousands of people using it daily. most of your 'complaints' here are not actually how git works in reality, and are just user error due to not bothering to learn the tool.

1. git never destroys your work inside a repository unless you told it to.

2. git doesn't 'whisk' things away implicitly. you committed them, that's pretty fucking explicit.

3. ummm every version control is stateful. wtf do you think any given version is? its fucking state. SVN has internal state, git, hg, fossil....

4. the commands, sure naming is fucking HARD we know this. we also know git gained different features over time to accommodate different workflows. perfect? absolutely not but a rose by any other name would smell as sweet.

[gmueckl]

From dissecting your comment, I am not sure how well you know git.

1. a) git's garbage collector runs without asking first. b) git's UI is so bad that users regularly end up in a state where they effectively asked git to destroy data without realizing it. It's often too implicit.

2. Ever modified a file between git add and git commit? Did these extra changes get committed? Some graphical clients try to hide aspects like this.

3. Unlike SVN, hg etc. git has superfluous extra state with complicated rules. The fact that the cache/index/staging area is inconsistently named three different things just illustrates how byzantine these rules are. And they can be done away with completely.

4. A rose by another name wouldn't smell as sweet - our senses of taste and smell are easily influenced by our other observations about an object. Human perception is weird. In the same vein, bad naming of features invites more usage errors.

[Buttons840]

Early in my career I was a junior developer on a team using SVN. I knew git and used a git plugin that let it work with SVN. I would often talk about various branches and things I was doing locally in my repository and the other developers would get concerned, because making a branch is SVN is a big deal, and here I am, it seems, making tons of branches. It was fun because when I would finally upstream my work, it would dump a dozen commits into the SVN history all within the same second. It was kind of nice having the linear history forced by SVN though.

[tempodox]

> that's just laughable considering SVN needs a central repo to work…

Do you use GitHub, GitLab, Bitbucket, gitea, ...? There's your central repo. If nothing else, it represents the “backup” facet of using an SCM.

[jimbob45]

>Once an SVN user discovers the magic of a staging area

You can already do that with TortoiseSVN or just through the cline

>stashes

SVN uses shelves

>git isn't hard

This feels like the "lisp is magic" argument that no one can seem to prove, despite how universal its proponents claim the law to be.