Git Is Not Revision Control

Git has always rubbed me the wrong way. The ability to rewrite history and not tracking file renames are a few of the reasons it has turned me sour, not to mention the awful inconsistent UX as brilliantly mocked in Git Koans. I'm not objective enough to come up with a solid case against git as a revision control system which is why this FreeBSD developer email from phk resonated with me enough that I flagged it and re-read it many times over the last year.

There was an internal discussion about the possible merits of switching to git to increase user contributions. This was his brilliant response, published with his permission:

On Sun, Feb 26, 2017, at 14:59, Poul-Henning Kamp wrote:
It is fundamentally wrong to ask "SVN or Git ?"

SVN is obviously a Version Control System, it has all the classic
attributes of one, including such crucial elements as progressing
version number a definitive timeline and imutability.

Git is clearly not a VCS, and it has never tried to be one, and
people calling it one doesn't change that.

The absense of a progressing version number and lack of a definitive
timeline, not to mention all the many "unnatural acts" you can do
to a git repo are sufficient arguments to settle this point.

No, Git is something else, it is a colaboration tool.

Git is a tool which allows people and projects to manage, modify,
fork and merge the many different views, instances, variations and
modifications of a work in progress across barriers of distrust.

The crucial word there was "many different", which is the exact
opposite of what a VCS strives for.

A lot of the features Git provides, features which are what makes
it great as a colaboration tool, flies in the face or or directly
invalidates the guarantees you normally expect from a VCS, most
notably progression of time & version, immutability and consistency
of view.

But in many cases Git is an adequate substitute for a VCS, you just
have to augment it with an out-of-band definition of which tree is
the 'definitive', and settle who gets to define what 'a version'
means.  This is why github exists in the first place.

In FreeBSD we have insisted on "proper version control" from
day one, 23 years ago, and while it is a decision we should
revisit periodically, everytime it has come up, it has been
overwhelmingly confirmed as "the way we do things here".

And this this thread, which is far from our first on the subject,
fails to converge:  One side desires better colaboration tools and
the other side is not willing to give up good old-fashioned version
control to get it, both parties failing to realize that neither SVN
nor Git will ever be able to do both, because the requirements are
fundamentally different and in conflict with each other.

So the task at hand, if there still is one, is to ask how we can
make it easier to use Git as a colaboration tool for our committers
and down-stream users.

Poul-Henning

PS: A good place to start would be to "bless" the github mirror
and make sure the pull requests there get dealt with:

    https://github.com/freebsd/freebsd/pulls

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@nospamplz           | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

I originally intended to cite specific points made in this email but honestly it's too good to not publish in its entirety. It's impossible to refute this line of reasoning in my opinion.