"""Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney ref-looking names that will end up confusing the users, and selling that as if it is a logical conclusion to "we want to give an easier to understand UI", without presenting a solid user experience design that is
convincing enough that the "idea" will reduce confusion will not get us anywhere"""
Here's the first example from the blog post:
# Why not replace things like: git reset HEAD -- file with:
> git unstage
What the author fails to realize is that you could have just said, "git reset file", which makes this `unstage` example much less convincing.
We actually do not recommend `git reset --hard` very often these days. `git checkout -f` is nicer alternative and is semantically related to `git checkout file`.
The 'stage' alias that adds and also understands deletions is a nice addition. It can be implemented as an alias. `git config --global alias.stage 'add -u --'`.
> While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom.
First you have to define the problem.
To me, git feels like building blocks that you use to create your own versioning system and workflow: you learn the tool, you discover which features are useful to you and you use only those. Another person (or group) will use a different process and a different set of features, effectively creating a different version control system.
So, in my opinion, git tackles the problem of being the foundation to a wide range of different VCSs, and does a pretty good job at that.
Something like this is tackling a similar problem to git-flow. Tools like this, with less features but that define or suggest a workflow are very useful, because they remove the confusion while you learn the tool and try to create your workflow at the same time, without knowing what the tool can do for you.
> To me, git feels like building blocks that you use to create your own versioning system and workflow
That's because it is almost exactly that. It helps to go back and read the earliest discussions of it.
Linus didn't build a version control system. He never really intended to. He built "gitfs" and equivalents of mkfs, fsck, cd, rm, mv, cp, and a thousand other tools for manipulating it.
Unfortunately, they were also built rather specifically to Linus's mental model and the kernel's workflow, so they look pretty funny to everyone else.
It's getting better. The git of 2012 is a lot friendlier than the git of 2005. But the impedance mismatch between what Linus was building and what the rest of the world expects is a long way from being eliminated.
http://thread.gmane.org/gmane.comp.version-control.git/18582...
http://thread.gmane.org/gmane.comp.version-control.git/17506...
Quoting Junio, the git maintainer:
"""Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney ref-looking names that will end up confusing the users, and selling that as if it is a logical conclusion to "we want to give an easier to understand UI", without presenting a solid user experience design that is convincing enough that the "idea" will reduce confusion will not get us anywhere"""
Here's the first example from the blog post:
What the author fails to realize is that you could have just said, "git reset file", which makes this `unstage` example much less convincing.We actually do not recommend `git reset --hard` very often these days. `git checkout -f` is nicer alternative and is semantically related to `git checkout file`.
The 'stage' alias that adds and also understands deletions is a nice addition. It can be implemented as an alias. `git config --global alias.stage 'add -u --'`.