20 Hacker News comments link this video. Each one links back to its thread.
fernandotakaiNov 2023Strongly recommends
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] ▶ this video
in “Confusing Git Terminology” · View on HN
Show 14 more comments
tmm1Oct 2007Strongly recommends
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. ▶ this video
in “What does News.YC think of distributed version control?” · View on HN
javier_e06Nov 2022Recommends
The post is a collection of rambling thoughts. The author should take a look at Linux Torvalds talk with Google (2009). ▶ this 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.
in “Scaling Mastodon is impossible” · View on HN
amouatNov 2016Recommends
I honestly don't believe it is an exaggeration. Take a look at this video for Linus's thoughts ▶ this video
in “Ask HN: Best Git workflow for small teams” · View on HN
ayewoSep 2022Cites it
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]
in “WebKit on GitHub” · View on HN
SllXJun 2020Cites it
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.
in “FreeBSD Renames “Master Boot Record” to “Main Boot Record”” · View on HN
est31Jun 2019Cites it
I hope this one is next: ▶ this video Also, I hope that they adopt flac. Right now they seem to use lossy codecs.
in “YouTube is working with Universal Music Group to remaster iconic music videos” · View on HN
simula67Jul 2018Cites 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
in “Version Control Before Git with CVS” · View on HN
solutionyogiAug 2014Cites it
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.
in “A look back: Bram Cohen vs. Linus Torvalds (2007)” · View on HN
WalkmanAug 2014Cites it
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
in “Why Git sucks?” · View on HN
hhsnopekAug 2014Cites it
> 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.
in “Project Gitenberg” · View on HN
skoreFeb 2014Cites it
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
in “Why is Git better than Subversion?” · View on HN
GoldenMonkeyFeb 2012Cites it
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 “Why Subversion is better than Git” · View on HN
gunsAug 2011Cites it
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
in “Linux 20 Years: Anecdotes from 1998” · View on HN
rachelbythebayJul 2013Critical
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: ▶ this 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 on "acting professionally"” · View on HN