Tech Talk: Linus Torvalds on git

I'd recommend darcs or git. Check out Linus' talk on git, he basically spends 70 minutes talking about why a distributed VCS is vastly superior to any centralized system. [VIDEO]

Watch this video and you will become enlightened as to why this is the case: [Linus Torvalds on Git] [VIDEO]

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." [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: [VIDEO]

A great speech @ Google on a subject directly apropos of pg's start-up spiel: [LINK] Another awesome speech from Google's tech talk series (it takes a little bit of tyrant to pull this off, tho): [VIDEO]

I only have one Linus story. Way back in 2007, he was supposed to come and give a talk on git. I had to do an on-site interview with a candidate immediately beforehand, but managed to get it done and got there in time to see the talk start. I had never seen him in person and figured it might be interesting, particularly since I had actually used git on some projects prior to that point. This wound up being recorded, and it's online here: [VIDEO] I think I lasted ten minutes and left after deciding it was too much. There was enough of that kind of energy going around already to willingly sit there and take in more. Besides, I had an interview to write up.

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 ( [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: ( [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.

I honestly don't believe it is an exaggeration. Take a look at this video for Linus's thoughts [VIDEO]

John Carmack is an absolutely brilliant speaker. Conversational, captivating and effortlessly natural. I could listen to him talk all day about the most arcane bits of graphics development which i'll never understand but am fascinated by regardless. His QuakeCon talks are particularly good. QuakeCon 2011 - [LINK] QuakeCon 2012 - [LINK] I like his talks because he's always interested by what he's doing and it tends to make me interested again in code. Linus Torvalds is another surprisingly good speaker. His talk on git - one of the dryest possible topics - was very interesting. There's not many other people I'd sit and listen to talk about SCM. [VIDEO]

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] [VIDEO]

I hope this one is next: [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: [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.

This can not be posted too many times. [VIDEO] Linus Torvalds talk on Google about how GIT is more a way of working then a piece of software. Everybody commits upwards in a tree of trust. If you do it this way you get automatic code reviews and in any team someone should be responsible for the "product" anyway and highest up in the hierarchy.

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 [VIDEO] and there's a transcript: [LINK]

The post is a collection of rambling thoughts. The author should take a look at Linux Torvalds talk with Google (2009). [VIDEO] back and day when development was centralized (no cloning). The concept of "Trusted Circles" is at the core any resilient information exchange and it is by definition: Decentralized.

you are getting confused here. what you have is a "paper receipt" (your checked out version) from your bank. something that, if you need an up-to-date version (from another remote), you need to request a new one (by issuing git fetch). git is, by default, distributed, so whenever you need to see the world outside, you need to be explicit. linus made it this way because back in the day (not sure right now tbf) tons of kernel developers do work without any internet connection, and would only connect to pull/send patches. this talk[0] by linus from 2007 (i remember watching it on google videos lol) explains really well where the git mentality came from. i really recommend it to you, since it feels like you are not really getting how git works. [0] [VIDEO]

This talk by Linus is iconic, if you haven't watched it you should. [VIDEO] He talks about what SVN got wrong, specifically, that it made branching easy and it's the merging that's the important piece. Git won because it made merging easy.