Tech Talk: Linus Torvalds on git

Linus repeats this line WRT distributed systems during his famous talk about git: "I have a theory about backups; I don't do them. I put stuff up on one site and everybody else mirrors it." this video

Coming from seven years of Subversion, I am amazed every time I 'cherry pick' a fix in Git to another branch. Subversion could never do that, it's file based versioning vs Git's content awareness is a paradigm shift. Subversion now seems to be nothing more than a file backup system. Linus Torvalds on Git: this video

In Linus Torvalds' talk on git at google[0], he mentions that the reason why he did not choose SVN (one of the reasons why he saw no other way but to build GIT) was that SVNs mission statement read "To create a compelling replacement for CVS"... which Linus hated with a passion and thus could not see why he would even use "a compelling replacement" of. Interestingly enough, in the 'Open Source projects and poisonous people' talk[1] with two SVN developers, they mention how they chose that line specifically to make sure that everybody is on the same page with the scope of the project - improving upon what people knew and were used to instead of wild, new things. Specifically because they would often have people come into the community with some grand plans that would have just exploded the scope. It is of course arguable to what extent there could be a general rule to this, but in this case, GIT is just so fundamentally and obviously the better option than SVN. Had somebody tried to make SVN into GIT, it would have simply killed SVN, so it was the right course of action to make it a new project. SVN was destined to die by its design. To see the GIT adoption rates these days (particularly due to tools like GitHub) is very encouraging to people who like to think that sometimes, starting over fresh is the only option. Of course, the thing you want to build really has to be that much better than the old thing you're trying to replace. So I agree with you - it's alright to say that

This article brings back memories. Back in 2007, I had just watched Linus' presentation on Git at Google ( this video ) where he called all non distributed version control systems as useless. I could not make any sense of the DVCS from his talk. I tried to play with Git and it was extremely frustrating due to the poor CLI. I thought may be Git is just a fad. But then more and more people kept talking about how awesome it is. This was one of the article where Git finally clicked for me. The key quote: There is no need for fancy metadata, rename tracking and so forth. The only thing you need to store is the state of the tree before and after each change. What files were renamed? Which ones were copied? Which ones were deleted? What lines were added? Which ones were removed? Which lines had changes made inside them? Which slabs of text were copied from one file to another? You shouldn't have to care about any of these questions and you certainly shouldn't have to keep special tracking data in order to help you answer them: all the changes to the tree (additions, deletes, renames, edits etc) are implicitly encoded in the delta between the two states of the tree; you just track what is the content. It's been 7 years since I have been using Git and I can't imagine how I ever worked with version control which didn't work on the entire tree.

No offense, but seems your problems coming your unwillingness to learn git properly. If you would take the time and learn it (reading Pro Git book, learning from visual tools, which there are a ton, etc) (Again, no offense, just suggestion.) > Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things. You don't need to know all 148 of them. If you only know 16 (1/9 of them): add, branch, checkout, commit, config, fetch, log, pull, push, rebase, reflog, remote, reset, show, stash, status, You can do pretty complex things already. For day-to-day usage, these are more than enough. > git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. Git rebase enables very simple workflows, like the GitHub workflow[1], which IMO is quite simple, small overhead workflow, pretty useful and scalable. Git rebase is also for local repo only. In every tutorial and even git command recommends against pushing rebased branches to an already pushed remote repository. If you keep this in mind, it makes sense. > ... to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, ... I think the reason is not that they want to hide their mistakes, but to clean the history. Would you rather see typos in a history? IMO it's just cruft, an amend or rebase pretty much just a clean up you can read it more easily, and you don't h

> Every time a programmer has an issue with Git, whoever helps them has to sit down and explain the underlying system for 20 minutes and draw a bunch of sticks and bubbles. This isn't true at all for a lot of people. I know a lot of people that just read the docs and are able to solve the issues. Others will Google the problem and find the solution on stack overflow. Everyone learns differently... > Anytime someone shoe-horns it into a product they talk about how Git is so amazing and solves all these problems, but what they are really talking about is just a version control system, not Git specifically. Git is amazing and does solve a lot of problems, but there are problems that aren't solved by Git. Even Linus himself says this here: ( this video ). Using the github API, rather than git, for creating epub books and pdfs is a great. Using git to control changes as the do is perfect as well. > Non-programmers will never put up with this. Ermm don't assume that everyone gives up right away. With the GUI interfaces we have today, Git is really simple once you learn it.

What would version control look like after Git ? Git famously was not built for monorepo [1] I would like to see sub-tree checkouts, sub-tree history, storing giant asset files in repo ( without the git-lfs hack ), more consistent commands, some sort of API where compilers and build systems can integrate into revision control etc [1] this video

I hope this one is next: this video Also, I hope that they adopt flac. Right now they seem to use lossy codecs.

In the case of git, Linus did what he did with Linux and named it after himself. EDIT: this video I didn’t watch through it again to confirm, but if my memory isn’t failing me, it was this talk where he mentioned his naming strategy.

IIRC, svn was marketed as "CVS done right" [1], which meant devs who were exploring alternatives to CVS didn't have to worry about svn's learning curve. So, I think inertia may have been a huge part of why adoption of svn was so good compared to git that has a steep learning curve, even today. 1: Of course, Linus Torvalds believes you can never do CVS right this video and there's a transcript: link