[falling]

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

[nknight]

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