
Git Is Not Revision Control (2017) - Daviey
https://blog.feld.me/posts/2018/01/git-is-not-revision-control/
======
jtmarmon
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

~~~
quotemstr
> 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

What's truly terrifying is this style of argumentation being applied to
_every_ technical decision.

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

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

~~~
lowry
This guy is Paul-Henning Kamp.

~~~
quotemstr
So what? He could be the almighty blogging from a burning bush and he'd still
be wrong.

------
Smaug123
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/](https://jneem.github.io/merging/) for a
glimpse of what a distributed version control system could have been.

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

~~~
muxator
With Mercurial you can rewrite history like an Orwellian Minister of Truth :)

It's just a bit harder for newbies to shoot themselves in the foot.

~~~
develop7
Um, no, you cannot really rewrite so-called "published" history (one with the
"public" _phase_ ). Both Git newbies and seasoned users could make use of such
concept, should it be ever implemented (it probably wouldn't in vanilla though
since the deafening silence in reply to anyone voicing ideas to prevent
rewriting (some) shared refs).

------
mehrdadn
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?

~~~
bb88
It can't. Even SVN at some point has some sort of data structure that can be
modified by an admin.

Data is not permanent unless it's somehow written into the permanent fabric of
space/time, and if you think about it long enough, deleting an svn or a git
repo is just another way of changing history.

~~~
mchahn
> Data is not permanent

A blockchain is getting close to permanent. I wonder if there is a blockchain-
based version control.

~~~
bb88
Well, if you look at the number of abandoned alt coins and torrents out there,
it seems far from permanent. Coinopsy has a list of abandoned coins if you're
curious.

And even if you had history in a blockchain, it's possible for someone to
prevent you from seeing the blocks that come in the future (breaking/filtering
your internet connection), which is also in a sense changing history (by means
of denying the future).

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

~~~
alkonaut
I find it very useful for questioning things like “If I’m on rev 1000 and see
the bug and you are on rev 990 and don’t see the bug then we have 9 possible
culprit commits”.

This is possible to talk about in git given “HEAD~N” etc but it’s cumbersome.
Git should out of the box have support for the default scenario: there is a
blessed branch on a blessed server. Revisions-as-numbers are the ordered
(first parent) commits on that branch. Probably easy enough to hack into a
tool, but to me it’s a mystery why this isn’t part of the standard behavior.

~~~
akx
> “If I’m on rev 1000 and see the bug and you are on rev 990 and don’t see the
> bug then we have 9 possible culprit commits”

Sure, that's easy for humans, but on the other hand “If I’m on rev 4093e8 and
see the bug and you are on rev 9b6dd8 and don’t see the bug then we have $(git
log --oneline 4093e8..9b6dd8) possible culprit commits” works just as well.

As for why there is no blessed-branch-on-blessed-server-and-commits-are-
numbered-there behavior, it's just not conceptually clean for a distributed,
decentralized version control system. GitHub or GitLab or Bitbucket could
build this sort of behavior... but it still doesn't feel very Git-y.

~~~
alkonaut
> then we have $(git log --oneline 4093e8..9b6dd8) possible culprit commits”
> works just as well.

It does - but that’s also why it’s so annoying that it’s behind a very
cumbersome cli front end.

As fotdistributed vcs: I realize that Git was designed as decentralized, and
almost not even designed as version control - just a “stupid content manager”,
and that higher level functionality is built on top (such as GitHub). But that
doesn’t change the fact that the 99 or 99.9% use case is _centralized version
control_ in the sense that there is a central blessed repo, making it
absolutely trivial to agree on a shared global history in git just like in
subversion.

I still think this sort of behavior should be part of core git, ie a higher
level functionality layer of the kind now added by GitHub or some plugin code.
Such as features for the centralized development model that _almost everyone
uses git for_.

These features include:

\- file locking for non-text content (now available e.g in lfs).

\- pull requests (now added eg by GitHub)

\- Simple chronological history

Etc.

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

~~~
kjeetgill
I remember a time before I understood git. I was working on a small team where
no one did and never really wrapped my head around it while I was there. 99%
of the git you use is super obvious once you understand it. It took just a
week or two sitting next to someone I could bounce questions off of and the
groking was complete.

It's powerful and I can't using imagine a VCS without getting to manipulate
(rebase) history but I do remember a time when it was opaque to me.

~~~
tatersolid
> It took just a week or two sitting next to someone I could bounce questions
> off of and the groking was complete.

That is insane. At $dayjob we teach SVN to non-devs (graphic designers and
marketing types) in 30 minutes, and never have to train them again. They even
do merges.

Git is truly a cool tool under the hood, but the UX is a massive drain on
productivity.

We should be trying to get _more_ non-technical people to use VCS in lieu of
Sharepoint, not having engineers spend weeks to “grok Git”

~~~
majkinetor
Totally this.

I use SVN exclusively when non-IT people are involved, such as designers, site
editors etc. Random person and even those without high school diploma can grok
SVN in less then an hour, particularly as you don't need to `git pull` all the
time which is HUGE saver as most people in the team work on independent
repository paths and thus git pulls are meaningless. Git stage is also more of
an obstacle then a benefit in that context.

Everybody using computers should know SVN, I consider it as basic as managing
files.

Git is great tool, but IMO targeted at developers.

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

