This is a good example of the kind of naivete that doesn't actually help
people use Git in the real world
The people I am referring to are not 'software developers'. I mentioned
documentation writers, testers, web designers, etc. They don't need and
_don't want_ to manage branches. Yet, every git-pull is potentially a merge
and git-rebase requires understanding of what commits are, the relation
between hashes and commits, etc.
Take the following example error message, which while technically very
meaningful, would be utterly confusing to them:
"error: failed to push some refs to '....'
To prevent you from losing history, non-fast-forward updates were rejected"
Refs? non-fast-forward? WTF?
Whether they have been 'damaged' by using 'inferior VCS' is
questionable, but regardless, they are what they are, and they may be fully
competent at their respective jobs without understanding Git or knowing
what a SHA hash is.
From experience, the lock-modify-unlock model and Visual Source Safe
specifically, is the best VCS for non-developers. They really really like
that by default a file can be checked out and modified only by a single
I am thinking that the right solution to this kind of problem may be to
develop reverse bridges. A bridge from Git to SVN, or from Git to VSS. So
that the main repository can be kept in Git, but parts of the team can
interact with it through the safe environment of "lock-modify-unlock".