Git Is Not Revision Control (2017)

I feel like there isn't much of an argument made here. It's just "we chose VCS and we're clearly right" with the veneer of examples.

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

OK - all of these things you can get by having a central authority thereby creating a VCS (by your definition) out of git. So git matches your definition of a VCS under constraints you already have.

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

Oh great so you agree that you can make git into a VCS based on your definition. So what's wrong with git again?

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

Ah, it's just not "the way we do things here". That's what's wrong with git. Got it.

An argument that might make some sense to me is "the beneficial collaboration features we'd get out of git isn't worth the switching costs". But I just found this written so matter o-factly ("It's impossible to refute this line of reasoning in my opinion.") for something that seems to make no actual point at all

In my opinion, this is mental gymnastics to try to eliminate git from some discussion. There's nothing of merit here. Plenty of people use Git every day to control their software revisions and it works just fine.

This argument is absurd. Git is clearly useful for revision control tasks, and so if it doesn't meet this guy's definition of a revision control system, the definition isn't particularly useful. The proof of the pudding is in the eating, even if someone doesn't think the delicious pudding qualifies as pudding.

From the title, I was rather expecting an argument along the lines of "Git is not revision control of code, but of snapshots of a filesystem"; I opened the link expecting to see an introduction to a patch-based system like Darcs or Pijul.

Pijul's theory, in particular, is extremely intuitive (if your intuition extends to "cocompletion of the category of files and patches", anyway) and it truly is born for the task of versioning text (and hence code). Git, by contrast, versions anything, with the result that very weird and counterintuitive things can happen when you merge branches. I recommend https://jneem.github.io/merging/ for a glimpse of what a distributed version control system could have been.

For me, rewriting history is a feature of Git, and not a bug. I used to use Mercurial, which prioritized immutability of history, and I found that I was too frightened of some of the more advanced features with not-obvious side effects to bother messing around with them, because if I messed up, there was often no easy way for me to revert my repository back to the way it was. Immutability of the central repository is a reasonable thing to want, but let me blow up my own local clone if I want to.

What's more, I find that phk's tone and the blog's tone are at odds with each other. The blog seems to have the attitude of "Git sucks and this is why", while phk's e-mail is far more interesting, instead arguing that Git fits into another class of software entirely and saying "It's not for us, but that's okay, and oh by the way we should probably accommodate those who prefer git".

How could software prevent rewriting history though? It can't be physical impossibility. If ensuring client rejection is a solution to this, then won't a git client also reject history changes?

What's so important about progressing version numbers for commits?

I don’t understand why git so hard for people. Just

> $ git help everyday

And start from there. It’s really quite easy, and I’d even say the single best designed piece of software I use everyday.

> There was an internal discussion about the possible merits of switching to git to increase user contributions.

That's a great discussion for a FLOSS project to have. It makes me think of a broader issue of how to judge whether or not to devote time to contributing to a given project.

Here's the logic I'd use as a reference case for making that decision. Hopefully others agree, or if not have some feedback for my course of thought...

The two reasonable initial branches to take in a discussion of changing the repo tech are a) that increased contributions are an important priority for the project at this time, or b) they are not. If consensus is they are not, there is little reason to discuss switching to git (or at least no urgency in this context).

If it is a priority, then there there are two obvious follow-ups: a) whether changing to git would even increase contributions to a significant level, and b) the cost of switching to git.

These are the obvious follow-ups because a) git is wildly popular with an enormous knowledgebase accessible in the usual places, and b) git is stable, actively maintained, and has lots of stable, actively maintained tooling around it.

As a side-note, I can think of an unlikely yet possible objection: that the popular usage of git has a design flaw that causes data corruption, catastrophic usability issues, or security problems that are trivially avoided with other stable, actively-maintained software. But outside of that, it seems to me a healthy functioning project would focus their attention on the branches I outlined above.

A nice side-effect of such focus is that a community could quickly make a decision (e.g., "too costly for too little gain atm") without stepping on toes or closing themselves off from future discussion. (Alternatively, they could spend more time and even take a more assertive position, but again without starting flamewars or unduly closing off future possibilities.)

To me, any of these branches seem like a sign of a functioning developerbase that is minimally welcoming from an outsider's perspective, and not so likely to waste new developer's time.

> On Sun, Feb 26, 2017, at 14:59, Poul-Henning Kamp wrote:

> It is fundamentally wrong to ask "SVN or Git ?"

I'm stuck here. I can't figure out how this could be a relevant branch to take in such a discussion, nor how a project could have a leader who so casually takes this branch.

Keep in mind one obvious branch I mentioned above was consensus on a desire to increase contributions. Even if that isn't a priority now, it's always a potential priority in the near future. But now if that ever becomes the consensus, the project will have an immediate inescapable conflict because everyone knows a leading dev doesn't even think git is a VCS. And even without a leader opining, someone is going to reference this obscurantist notion that git and SVN cannot be compared. Remember the time so-and-so wrote that screed, and do we agree with it it?

It's a guarantee of wasted time, both now and more importantly in the future of the project.

Honestly, I find the quoted message fascinating wrt the history of version control in FreeBSD. I can see why the author keeps coming back to it.

But as part of a FLOSS dev-process it looks quite dysfunctional to an outsider. If I make a suggestion to switch from SVN to git in order to increase contribs, the response should not feel like it was chosen by spinning a roulette-wheel of obscurantist responses. (And even then, the obscurantist response probably shouldn't alienate the entire userbase of Github.)