Git Is Not Revision ControlSun 21 January 2018 by feld
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.