Git Is Not Revision Control (2017)(blog.feld.me)
blog.feld.me
Git Is Not Revision Control (2017)
https://blog.feld.me/posts/2018/01/git-is-not-revision-control/
31 comments
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.
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".
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".
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.
It's just a bit harder for newbies to shoot themselves in the foot.
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).
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?
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.
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.
> Data is not permanent
A blockchain is getting close to permanent. I wonder if there is a blockchain-based version control.
A blockchain is getting close to permanent. I wonder if there is a blockchain-based version control.
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).
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).
There is. Git.
You can easily prevent this on the server side. The protected branch feature of Github prevents history rewriting for example.
What's so important about progressing version numbers for commits?
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.
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.
> “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.
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.
> 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.
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.
Comparability, presumably.
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.
> $ 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.
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.
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.
> 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”
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”
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.
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.
If that were true, this wouldn't exist:
https://xkcd.com/1597/
https://xkcd.com/1597/
Hilarious! Most git tutorials cover how to pull, commit, push, and maybe merge. I think what is missing from most git tutorials is just how to get the repository into a good state if you're confused.
git commit -am "Oh No" && git branch BACKUP && git checkout origin/master -b attempt2; # EZ PZ
The BEST thing about git is that you can easily do the equivalent of save everything (commit), back it up (branch), and pull up a clean version (checkout). What they're describing should be the selling point of git!
git commit -am "Oh No" && git branch BACKUP && git checkout origin/master -b attempt2; # EZ PZ
The BEST thing about git is that you can easily do the equivalent of save everything (commit), back it up (branch), and pull up a clean version (checkout). What they're describing should be the selling point of git!
> 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.)
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.)
> 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