HN Theater @HNTheaterMonth

The post is a collection of rambling thoughts.

The author should take a look at Linux Torvalds talk with Google (2009). https://www.youtube.com/watch?v=4XpnKHJAok8 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.

Linus’ original talk might be good

https://youtu.be/4XpnKHJAok8

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 https://www.youtube.com/watch?v=4XpnKHJAok8 and there's a transcript: https://gist.github.com/dukeofgaming/2150263

⬐ ReptileMan

Unpopular opinion - git is just not that good of a source control tool. Amazing as a distributed system, but mediocre in its primary function.

⬐ antris

Source control is an inherently distributed system. Each developer has their own copy of the code that are distributed across many computers, and they need to communicate between each other. That's exactly what the primary function of the software is.

⬐ ReptileMan

Git is true mesh source control system. You only need one .git folder to survive and you haven't lost anything. My memory is fuzzy but with svn if you lost the central repository you were in a world of hurt.

This is what git does right. What git lacks for me is smoothness in interaction with the user. To use git well you must think like git. Which is kinda annoying when I prefer my tools to think like me.

When I moved from svn to mercurial it was absolutely painless. On my next company git was terrible experience. I am sure that git tools and flexibility are amazing for linux kernel and other projects of the scale. But probably are overkill for smaller stuff when a more friendlier user flow will be nice.

⬐ flohofwoe

That's just as true with SVN, (for the local in-progress working copies) but with a single, centralized history. Which is how most devs use git anyway (essentially emulating a centralized versioning system workflow), and in this case the distributed nature of git allowing many alternative histories is unnecessary in the best case, and massively gets in the way in the worst case (because for most projects a single history is actually a feature).

⬐ saurik

(In a very real sense, the server from Subversion does the same job of the optional server from Operational Transform: it is acting as a sequencer. The next thing we could do is replace that with proof-of-work, and then we could have a fully decentralized system with the properties of Subversion ;P.)

> But "not changing commit IDs" isn't part of git's utility.

How is that not a useful, intentional feature of git? Commit IDs (hashes) ensure DAG consistency as well as many other benefits. Linus explains it better than I could[0].

> This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have.

It depends on the context. Try to rewrite commits in a PR for any public repo and see whether others agree it's a useful feature.

Anyway, I think you're proving the counter point: this is a shared feature of git and block chains - you know when history has been rewritten because the hashes changed.

[0] http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s

⬐ knorker

Sure, it's a hiccup to rewrite history. But in Bitcoin it's 100% fundamental breakage. There's a difference.

⬐ MayeulC

I think you didn't take the parent's suggestion to make a PR seriously enough.

It is closer than you seem to think: rewriting history in a public, published repository will wreak havoc across contributors'clones. Contributors will have to contact upstream and ask if there was a reason, if it was intentional, or a malicious event. Especially if the root commit was changed, in which case you can't even attempt to merge repositories.

I don't really see why you couldn't backtrack the bitcoin blockchain, pretend an arbitrary block is the most recent one, and start your fork from there. The difference is,is that if you want to include some subsequent blocks, you will have to provide some proofs of work.

In both cases, some convincing is needed to move the consensus base to a new one.

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

In the important note:

> One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

Also:

> it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite

This is git 101. People can still choose to follow your rewritten history fork though, and it's also the case for bitcoin.

⬐ knorker

I replied to most things here in https://news.ycombinator.com/item?id=32443447

In git it's a hiccup if upstream does it. But it does work. For buttcoin you get the DAO split.

There's also this Tech Talk Linus gave in 2007 -

https://youtu.be/4XpnKHJAok8

You might get a kick out of this. Tech Talk by Linus Torvalds at Google presenting Git: https://www.youtube.com/watch?v=4XpnKHJAok8 . He goes into his thought process of the pains with existing version control systems and how Git goes to address their shortcomings.

Some clues are available in this video: https://www.youtube.com/watch?v=4XpnKHJAok8 (Tech Talk: Linus Torvalds on git). There's nothing conclusive about the length of the pondering, but he does say the writing itself took two weeks:

"I decided I can write something better than anything out there in two weeks. And I was right." [1]

[1]: https://youtu.be/4XpnKHJAok8?t=736

In the early days it was literally a “request to pull from me” - one would literally email Linus (for example) “hey, I made X changes, consider pulling them from Y (an attached file, or a server)”

Linus talks about this in a great panel he did at Google 14 years ago: https://youtu.be/4XpnKHJAok8

This can not be posted too many times.

https://www.youtube.com/watch?v=4XpnKHJAok8

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.

⬐ jeffbee

It's a great example of how Linus has a massive blind spot for the failings of the git model. He's "sorry" they use Perforce. Git is "better than everything else out there" but he doesn't mention Perforce. And yet, the Perforce model is the one that got Google to be one of the fastest-moving organizations on the planet, with the biggest code base.

⬐ dogleash

>And yet, the Perforce model is the one that got Google to be one of the fastest-moving organizations on the planet

Google could have dogshit version control still succeed just through sheer headcount. Why does anyone act like they're a perforce success story?

⬐ nix0n

> the Perforce model

I've used both Git and SVN enough to understand how a VCS might change how an organization creates code, but I've never used Perforce. What is "the Perforce model"?

⬐ jeffbee

In Perforce the concepts are different. You have a client, with a view that includes a subset of the repo, and you have changelists which incorporates your related edits. When done with a changelist, you submit it to trunk, usually, because while you can branch a Perforce repo, you mostly don't need to.

Basically all the stuff in the first half of the talk where he whines about stepping on toes, conflicting with other people, politics, special write access groups, are all non-issues that do not sound familiar to Perforce users. If two people are using Perforce they can both work on changes to the same files taken from the main branch (trunk) and submit them separately without conflict or even awareness of the other person. As a bonus this is all dramatically faster in Perforce than in git for large repos.

In this talk Linus demonstrates that he believes git is a state-of-the-art SCM system, without being familiar with the actual state of the art.

⬐ tick_tock_tick

> In this talk Linus demonstrates that he believes git is a state-of-the-art SCM system, without being familiar with the actual state of the art.

I don't think that's very fair Perforce is mostly just a shitty subset of git's features that some people pretend is sufficient. You can use git almost the same as Perforce and have almost as bad of an experience as using Perforce directly.

⬐ kubanczyk

Let's say we collaborate on the code below. I'll change line 1, you'll change line 5, we'll merge both changes and then we'll see how Perforce makes the code run successfully "without conflict or even awareness of other person".

    1  x := 0
    2  x++
    3  x++
    4  x++
    5  if x > 7 {
    6    fail_horribly_at_runtime()
    7  }

⬐ jeffbee

Explain how you think git is different in this regard.

⬐ detaro

You're the one that claimed Perforce was better than git and could do this "without conflict or even awareness of the other person", so why don't you explain how git is worse? (I've never used Perforce and am genuinely curious what clever kinds of things it can do around merges, but more detail than "it's state-of-the-art and git is not" would be useful)

⬐ jeffbee

No, it is Linus who makes a bunch of claims about how Perforce is worse, in the video.

If two people edit the same line of code based on the same original version, that's a conflict and there's nothing any SCM can do about it. Human must merge. But there's no reason that several developers can't work on different functions or other disjoint areas of the same file, unlike what Linus is claiming in the video.

The video is essentially a long straw-man argument where Linus takes shitty part of CVS and SVN, which were terrible, and applies them to Perforce, which it's clear he has never used.

⬐ LenP

To answer your question, neither Git nor Perforce will cause a merge conflict. You’d need a SCM that isn’t line-based for that.

With large teams, you need code review (which this bug can elide), great test coverage (the tests will likely have a merge conflict) and very importantly, a commit-by-commit build health indicator after merging. You can also do this in batches and bisect to find poisonous commits should a batch be broken - flakes notwithstanding.

Yes!

The problem is choosing a monorepo because the tooling isn't suited for monorepos.

Trying to build a monorepo with git is like trying to build your CRUD web app frontend in c++.

Sure, you can do it. Webassembly exists and clang can compile to it. I wouldn't recommend it because the tooling doesn't match your actual problem.

Or maybe a better example is that it's like deciding the browser widgets aren't very good, so we'll re-render our own custom widgets with WebGL. Yes, this is all quite possible, and your result might get to some definition of "better", but you're not really solving the problem you had of building a CRUD web app.

Can Microsoft successfully shim git so that it appears like a centralized trunk-based monorepo, the way you'd find at an old cvs/svn/perforce shop? Yes, they did, but they shouldn't have.

My thesis is they're only pushing monorepos because it helps GitHub monetize, and I stand by that.

> Tests should only execute against code that changed. Builds should only build the thing you want to build, not the whole repository.

How do you run your JS monorepo? Did you somehow get bazel to remote cache a webpack build into individual objects, so you're only building the changes? Can this even be done with a modern minimization tool in the pipeline? Is there another web packager that does take a remotely cachable object-based approach?

I don't know enough about JS build systems to make a monorepo work in any sensible way that utilizes caching and minimizes build times. If anything good comes out of the monorepo movement, it will be a forcing function that makes JS transpilers more cacheable.

And all this for what? Trunk-based development? So we can get surprise dependency updates? So that some manager feels good that all the code is in one directory?

The reason Linus invented git in the first place was because decentralized is the best way to build software. He literally stopped work on the kernel for 2 weeks to build the first version of git because the scale by which he could merge code was the superpower that grew Linux.

If you YouTube search for "git linus" you can listen to the original author explain the intent from 14 years ago: https://www.youtube.com/watch?v=4XpnKHJAok8

If this is a topic you're passionate about, I'd encourage you to watch that video, as he addresses why decentralizing is so important and how it makes for healthy software projects. It's also fun to watch old Googlers not "get it".

He was right then and he's right now. It's disappointing to see so much of HN not get it.

⬐ vtbassmatt

You have cause and effect reversed. There are teams/groups/customers running into scale problems with Git, and they aren't interested in switching away from Git. So we're teaching Git to meet their needs. There's not much of a moat (monetization potential) here since we're upstreaming everything to core Git.

Disclosure: I'm the product manager for Git Systems at GitHub, where much of this work is based.

⬐ anon9001

I understand that your customers want very large git repositories, so that's the need you're going to serve. As a (very large) bonus, you're going to sell a lot of cloud services to people that can't manage to work with their monorepo on local machines. I won't be surprised if in 5 years, most big companies are just leasing GitHub instances as the only reasonable way to edit/build/test/deploy all of their code from the browser. I think it's a concerning trend if you're not GitHub.

Also, I appreciate that you're upstreaming to core git and not trying to build a technical moat.

But why do so many people want these monorepos?

This seems like a serious developer education problem to me.

If I'm wrong that Google is the cause of this cultural shift toward monorepos, what do you think caused it?

I can't figure out why so many people are married to git but insist on leaning into its weaknesses (large repos) instead of its strengths (smaller composable repos).

In siblings to this thread, we have people reminiscing about the good old days of subversion and asking for git to emulate those features. It's quite frustrating to watch.

I think I've been operating under the illusion that most developers understood git well enough to realize it's a better model than svn. But in reality developers would have been more than happy to use "SvnHub" if that had come along first.

⬐ erik_seaberg

> its strengths (smaller composable repos)

I think this is happening because git submodules have a hard and confusing CLI even compared to the rest of git.

> would have been more than happy to use "SvnHub"

svnmerge.py caused almost as many trainwrecks as it avoided. I don’t think resolving merge conflicts can be made to work so long as the repo relies on being informed of all file moves and copies, because devs just didn’t do that consistently.

⬐ vtbassmatt

Thank you for your reply. I think you raise some great points, and I'll respond to a few that I have knowledge of.

> But why do so many people want these monorepos?

Google-copying is part of it for sure. And I agree with your position - copying Google isn't a great reason on its own. Some more valid reasons: code which deploys together often wants to live together. Common dependencies can be easier to find (and use) if they're right there in the repo. Related, making cross-cutting changes can be easier when you can make an atomic change everywhere. Also, big repos often started out as small repos and then grew over time; the cost of a major change might outweigh the friction caused by keeping Git in place.

Consider also that we might not all be talking about the same thing. Some people (even here in this topic) consider Linux to be "large" and "a monorepo". Linux isn't notably big anymore, and it's not unusually challenging to host or to use locally. It's arguably a monorepo since it contains most of the code for the Linux kernel, but to me, "monorepo" implies needing special attention. So I probably wouldn't classify Linux as a monorepo for this discussion.

> I can't figure out why so many people are married to git but insist on leaning into its weaknesses

I'm sure there are many reasons. The common one I hear in my role boils down to, essentially, "Git is the de facto standard". That can be expressed in several ways: "it's harder to attract and retain engineers with an uncommon toolset"; "we want to focus on our core business, not on innovating in version control"; "all the other tools in our kit work with Git". (NB: I put those in scare quotes to distinguish that they aren't my or GitHub's position, they're things I've heard from others. They're not direct quotes, though.)

I talk with customers weekly who want to mash dozens of independent repos (Git or otherwise) together. If they aren't going to reap any of the benefits mentioned above or elsewhere in this topic, I strongly advise against it. At the end of the day, GitHub doesn't care if you have one giant monorepo or 1000 tiny ones; the product works pretty well for both. I suppose that's why I felt compelled to reply to your thread in particular -- yes, we're investing in monorepos, but no, it's not because we're trying to drive people to them.

⬐ anon9001

Thanks for engaging in discussion about this. If nothing else, you're building my confidence in GitHub.

> Consider also that we might not all be talking about the same thing.

I think this is 90% of the confusion/disagreement in this thread.

I've always thought that it's fine to use git however you want, but if you hit a bottleneck (it gets too big and becomes slow), then you split your repo along logical boundaries (usually a large library can be split out and versioned, for example).

Somewhere over the last 15 years, that's changed, and the zeitgeist is now "mash dozens of independent repos into one repo" no matter the situation. Everyone in this thread that's suggested monorepos aren't the way to go has been downvoted, which caught me by surprise.

> I suppose that's why I felt compelled to reply to your thread in particular -- yes, we're investing in monorepos, but no, it's not because we're trying to drive people to them.

I believe you're sincere, and perhaps I was a bit too cynical about GitHub's motivations. Sorry about that, this topic is just frustrating and GH is in a position to help make things better.

Do you think GitHub could offer some kind of practical guide about when to use monorepos and what their limitations are?

I think part of the problem is that git's docs and the git-scm book aren't going to prescribe a way to use the software, because it's intentionally extremely flexible. Git users appreciate this, but GitHub users might lack good guidance.

As another reply pointed out, this might also have its origins in the git-submodule porcelain being confusing and underutilized.

Most GitHub users have probably never used submodules, don't know when a git repo would start to slow down due to size, aren't sure how to split out part of a repo while preserving history, and probably haven't thought too much about internal dependency versioning.

> to me, "monorepo" implies needing special attention

I think you and I are actually in total agreement, but the vast majority of corporate GitHub users have no context about where git came from, what it's good at, what it's limitations are, and how to use it for more than trunk-based development.

The ideas that "Linux is a monorepo" or "monorepos are the only natural way to manage code for any project" or that git should be "fixed" to support centralization should be concerning to GH.

I suspect these people don't have "monorepos" in the way that you and I are talking about them. They probably just have mid-sized repos that haven't need to be split up yet.

Even if you can support those customers as they grow into monorepos without friction due to enormous technical efforts, we're failing to teach a generation of engineers how to think about their most fundamental tools.

I appreciate that GitHub is trying to use technology to smooth out these points of confusion and improve git to work in every scenario, but publishing customer education materials about how to make good decisions about source code management would also help a lot.

> I talk with customers weekly who want to mash dozens of independent repos (Git or otherwise) together. If they aren't going to reap any of the benefits mentioned above or elsewhere in this topic, I strongly advise against it.

It sounds like you're giving good advice to the teams that you talk to, but what can I show my team that's authoritative from GitHub that says "don't mash dozens of independent repos together and then blur the lines so you can't tell what's independent anymore"?

I thought this was obvious, but it's not, and I don't know how to get people to understand it.

This is a particularly bad problem when your independent repos are working fine, but then there's a company-wide initiative to go "monorepo", and it's obvious in advance that the resulting monorepo won't be usable without a lot of extra work.

Maybe I've just been unlucky, but every time I've had a monorepo experience, it's been exactly that approach. And, as I'm sure you can tell by this thread, I haven't had much luck in convincing other engineers that mashing all unrelated code into one repo is a silly thing to do.

⬐ azornathogron

> But why do so many people want these monorepos?

Lots of people elsewhere in the thread have given reasons that I won't repeat, but I will say I think it's a very different situation for an engineering-focused company compared to, for example, open source projects.

In a company you get a lot of advantages from uniformity of tools and practices and dependencies across the many projects/products that the company has, and you have the organizational structure to onboard new employees onto that way of working and to maintain the level of uniformity and actually benefit from it.

In open source, every project and even every contributor is sovereign unto themselves. In this situation, the difficulties of cross-project changes are primarily human organizational challenges - even if you could collect a lot of projects into a monorepo, you couldn't get the big benefits from it because you wouldn't be able to get everyone to agree to stick to a single set of tools and do the other things that make monorepos powerful.

I think monorepos are great for companies.

But using git as a basis for a monorepo system is a bad idea for the reasons you suggest. It's totally the wrong tool for the job.

I remember the transition period when (nearly) everyone in the open source world moved over multiple years from subversion - or in some cases cvs - to git. The advantages of decentralised development for open source were really clear, and so was the way git tracked branch and merge history (when git was first developed, subversion barely tracked merge history at all, which made it easy to end up with bad merges after accidentally merging the same change multiple times). And at the scale of repositories in the open source world, git was massively faster than svn. But the speed doesn't scale, and if you've got a monorepo you almost certainly aren't doing real decentralised development, and the merge tracking in subversion was fixed (well... maybe; honestly I haven't been paying enough attention to be sure). So seriously SvnHub would actually be a better basis for the monorepo world. It's almost unfortunate that git took over so comprehensively that now companies want to use it for a different context where it really doesn't shine at all.

⬐ CRConrad

> subversion barely tracked merge history at all, which made it easy to end up with bad merges after accidentally merging the same change multiple times

Weird. Shouldn't that be just a no-op?

⬐ azornathogron

It's been more than a decade so I almost certainly oversimplified the problem.

But to give an approximate explanation: Subversion's model of how branches work is fundamentally different to git's model. In fact in a sense subversion doesn't have a concept of branches at all in its core data model. Subversion just gives you a directory tree with a linear history, and then makes it cheap to copy directories around. The recommended layout for a subversion repository looks something like this:

    - /tags
    - /tags/release-v1
    - /tags/release-v2
    - /branches
    - /branches/my-feature-branch
    - /trunk/...

If you want to create a branch you just copy your trunk directory to a new name under /branches. In order to reliably merge back & forth between branches or between a branch and trunk (which are just directories in the repository), you need more than just finding the diff between the latest state of each branch; you really need to know about the historical relationships between them: When the directory was created what was it copied from, what other merges have happened since then? But this information - at least "what merges have already been done" literally wasn't tracked until about subversion 1.5 (which was actually contemporaneous with a lot of the migrations of subversion to git, at least in my recollection).

Some references for you:

- The classic "svn book" about branching: https://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.ht... - note the section at the bottom "The Key Concepts Behind Branching" which notes "First, Subversion has no internal concept of a branch—it knows only how to make copies. When you copy a directory, the resultant directory is only a “branch” because you attach that meaning to it."

- The subversion 1.5 release notes explanation of merge tracking: https://subversion.apache.org/docs/release-notes/1.5.html#me...

To try to place this in time, I was using subversion (and was pretty happy with it!) in 2007. By 2009 I was using git wherever I could. Of course, the widespread migration toward git throughout the open source ecosystem was spread over a lot more years than this. But hopefully that gives some context.

⬐ CRConrad

Ah, thanks, TIL something again.

Seems (at least the original version you described of) subversion was in some/several/many ways genuinely inferior to git.

But yeah, having thought about it a bit more re-applying the same change again in any versioning system is of course not necessarily "a no-op" if they're not immediately following each other; if other changes that partially reverted the original ones have happened in between. Then re-applying the original changeset would of course re-do that part of the original changes.

Maybe this one?

Tech Talk: Linus Torvalds on git (2007)

"Linus Torvalds visits Google to share his thoughts on git, the source control management system he created two years ago."

https://www.youtube.com/watch?v=4XpnKHJAok8

⬐ car

Thank you, but I don’t think this was it. The one I remember was more technical. However, I did discover Gilfoyle at 21:40 ;).

If it weren't for Linux, git wouldn't have existed; git was Torvalds scratching the itch that was needing a better way to manage the Linux source.

He's an outspoken detractor of subversion [1], and after bitkeeper went pear-shaped [2], two projects sprang into being around the same time, solving the problem: Git, and Mercurial [3]. Whichever you think is better, when Torvalds converged on git as the choice for the kernel, the rest of the world could but follow.

[1] https://www.youtube.com/watch?v=4XpnKHJAok8 [2] https://lwn.net/Articles/130746/ [3] https://en.wikipedia.org/wiki/Mercurial

⬐ pseudalopex

The world followed GitHub. Not Linux.

Hey, Linus Torvalds had a word to all those CVS users a few years ago in a Google . https://www.youtube.com/watch?v=4XpnKHJAok8

While this is true, I think Git is quite different. Linus has said that he's not really a "VCS guy", so apart from high level architecture and high level concepts of what Git actually is as a VCS, he hasn't really had as much impact on Git's codebase as much as Linux.

Antirez, on the other hand, has had a large part in the continued development of Redis since it's inception, so like, 11 years or so (2009).

AFAIK, apart from UI improvements over the years, Git has _largely_ been the same since inception, in that you can watch a video as far back as e.g https://youtu.be/4XpnKHJAok8 and not much has really changed since those days (by the time Linus gave that prez, Junio already started running the project).

If you let Github become a single point of failure, maybe you are using git wrong? It's named "Distributed version-control" for a reason. I can really recommend this talk by Linus Torvalds about how git is more of a way of working than a piece of software: https://www.youtube.com/watch?v=4XpnKHJAok8

⬐ yingbo

I may use git wrong, but didn't use GitHub wrong. First, Github provides more functions than a git repo. Second, I haven't seen anyone or any company using Git in the way as Linus said in the video. I believe most companies are not either.

⬐ kasey_junk

The git aspects of github are not the things people build SPOF on.

It’s the code review tooling, the artifact storage & the deployment pipelines.

A distributed version of those would be awesome...

In the case of git, Linus did what he did with Linux and named it after himself.

EDIT: https://youtu.be/4XpnKHJAok8

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.

Branching by cloning was copied from bitkeeper. It was also early git's only branching mechanism. If you listen to Linus's talk when he introduced git at Google, you'll hear him conflate "branch" with "clone" because that's what he was thinking of at the time.

https://www.youtube.com/watch?v=4XpnKHJAok8

> 1. Linux source was hosted on BitKeeper before git. It basically was one of the first distributed source control systems (or the first? not sure if anything predated it).

There were several systems which predated it. The most arcane one I know of is Sun's TeamWare[1] which was released in 1993 (BitKeeper was released in 2000). It also was used to develop Solaris for a fairly long time.

Larry McVoy (the author of BitKeeper) worked on TeamWare back when he worked at Sun.

> 2. Linux devs got into conflict with the BitKeeper owner over open-sourcing and reverse engineering, so Linus realized they needed a new system because no other source control system had the features they needed like BitKeeper had (mainly, I understand, the distributed repos).

That is the crux of it. Linus does go over the BitKeeper history in the talk he gave at Google a decade ago on Git[2].

[1]: https://en.m.wikipedia.org/wiki/Sun_WorkShop_TeamWare [2]: https://www.youtube.com/watch?v=4XpnKHJAok8

I hope this one is next: https://www.youtube.com/watch?v=4XpnKHJAok8

Also, I hope that they adopt flac. Right now they seem to use lossy codecs.

⬐ klodolph

They don’t necessarily use the same codec for YouTube’s master copy and the one that you get served. From what I understand, you can upload whatever codec you want to YouTube, and presumably it gets kept in its original format, so it can be transcoded however you like for serving. Anything else doesn’t make sense. Transcoding to FLAC would make sense if you uploaded PCM to begin with.

⬐ adrianmonk

I think a reasonable middle road, since most people won't notice or care about the difference, is to support something lossless like flac but not make it the default.

The people who really care could turn it on (perhaps at the account level), and they'd be happy, and YouTube still saves on bandwidth costs.

⬐ jorvi

320kpbs MP3 is already transparant. FLAC is mostly for archival purposes.

⬐ vectorEQ

they probably would refer to them as bandwidth saving codecs :D but you're right

⬐ teilo

Yeah, but 160kbit Opus is so good that it's rarely worth it to use Flac. I've done 180º phase cancellations against uncompressed on a variety of sources, and it is so close to transparent that one would have to be have some serious OCD to be unsatisfied with it, and even then could not A/B it in a blind test with better than 50% accuracy except on rare source material, and then just barely.

⬐ mixmastamyk

Opus is great but its barely worth it to skimp there when compared to HD video. Still, archive copies aren't youtube's forte. Makes sense for them, but I wouldn't convert my personal audio collection with storage so cheap.

⬐ teilo

I was responding to someone lamenting the fact that they stream in Opus instead of Flac. There is zero advantage to be gained from streaming in Flac. So why the lament? If they store archival quality, they wouldn't ever be streaming it anyway.

Furthermore, you underestimate the amount of bandwidth savings when you multiply it over millions of viewings. It really adds up. It totally makes sense for them to use Opus. They save money, and the viewer loses nothing. Shaving pennies is an effective way for a business to cut expenses. Thousands of small changes, insignificant by themselves, can have a significant impact on EBITDA.

⬐ mixmastamyk

> Makes sense for them,

(i.e. Youtube)

⬐ chupasaurus

Even though all music I have on my drives is in FLAC, I can't differ it almost always from Opus 160 kbps, which is what they're using now (but most of the stuff is reencoded from previous codecs).

⬐ est31

Yeah I guess that most people won't be able to notice any difference except for the additional traffic needed. FLAC is probably mostly useful for "masters" you keep and re-encode to the currently best lossy audio format (opus at the moment). This way you avoid generational artifacts.

⬐ chupasaurus

That's obvious. I assume YT got lossless records from labels for their Music offering.

I really think showing them how it works visually with a DAG is a great way to show someone how git works. Also, Linus has a great talk about git and how it works here: https://m.youtube.com/watch?v=4XpnKHJAok8

(Sorry for mobile link, I'm on my phone RN)

I still recommend people to watch this video from the man himself, Linus Torvalds, if they really want to understand the architecture and data structure behind git - https://www.youtube.com/watch?v=4XpnKHJAok8

If I remember correctly, he mentioned that he wrote the MVP in 4 weeks and the data structures he used are quite simple. Never got a chance to look at the source code but I guess they are in github (at least the mirror copy.)

⬐ nickthemagicman

It only took 4 weeks plus 30 years of programming experience and a genius mind.

there was great excitement and adoption before github

famous linus talk at google 2007 https://youtube.com/watch?v=4XpnKHJAok8#

github founded 2008 https://wikipedia.org/wiki/GitHub

git's distributed nature was revolutionary. Although not the first (BitKeeper for one preceded it), it has a mind-numbingly simple design, of distributed data by content addressing (data named by its hash, so it has the same name whereever it is).

> So having run into this problem, folks like Google, Twitter, etc. use monorepos to help address some of this.

I think you’re retroactively claiming that Google actively anticipated this in their choice at the beginning of using Perforce as an SCM. They may believe that it’s still the best option for them, but as I understand it, to make it work they bought a license to the Perforce source code forked it and practically rewrote it to work.

Here’s a tech talk Linus gave at Google in 2007: https://youtu.be/4XpnKHJAok8

My theory (I wonder if someone can confirm this), is that Google was under pressure at that point with team size and Perforce’s limitations. Git would have been an entirely different direction had they chosen to ditch p4 and instead use git. What would have happened in the Git space earlier if that had happened? Fun to think about... but maybe Go would have had a package manager earlier ;)

⬐ edejong

Maybe Google’s choice for monorepo was pure chance. However, on many occasions the choice was challenged and these kinds of arguments were (successfully) made in order for it to stay.

⬐ thomaslee

> I think you’re retroactively claiming that Google actively anticipated this in their choice at the beginning of using Perforce as an SCM.

Oh I didn't mean to imply exactly that, but really good point. I just meant that it seems like folks don't typically _anticipate_ these issues so much as they're forced into it by ossifying velocity in the face of sudden wild success. I know at least a few examples of this happening -- but you're right, those folks were using Git.

In Google's case, maybe it's simply that their centralized VCS led them down a certain path, their tooling grew out of that & they came to realize some of the benefits along the way. I'd be interested to know too. :)

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] https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...

⬐ mmphosis

WWgitND, or “What Would git Not Do.

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 - https://www.youtube.com/watch?v=4zgYG-_ha28

QuakeCon 2012 - https://www.youtube.com/watch?v=wt-iVFxgFWk

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.

https://www.youtube.com/watch?v=4XpnKHJAok8

Linus Torvalds' talk on Git: https://www.youtube.com/watch?v=4XpnKHJAok8

⬐ None

None

IIRC that's almost exactly what Linus said about git: that it's rather a toolbox for creating SCM rather than SCM itself [0].

[0]: http://www.youtube.com/watch?v=4XpnKHJAok8

⬐ dgellow

Could an admin add '2007' to the title and fix Linus name?

Linus: "You can have people who try to be malicious... they won't succeed."

Linus talked about why git's use of a "strong hash" made it better than other source control options during his talk at Google in 2007.

https://youtu.be/4XpnKHJAok8

Edit: the whole talk is good but the discussion of using hashes starts at about 55 min.

> but git doesn't actually just hash the data, it does prepend a type/length field to it.

To me it feels like this would just be a small hurdle? But I don't really know this stuff that well. Can someone with more knowledge share their thoughts?

I think Linus also argued that SHA-1 is not a security feature for git (https://youtu.be/4XpnKHJAok8?t=57m44s). Has that been changed?

⬐ lamontcg

Yeah what is the attack here?

If you don't have permissions to my repo that already limits the scope of attackers to people who already have repo access. At that points there's tons of abuse avenues open that are simpler.

If someone could fork a repo, submit a pull request and push a sha for an already existing commit and that would get merged and accepted (but not show up in the PR on github) well that would certainly be troubling, but at that point I'm well past my understanding of git internals as to how plausible that kind of attack would be...

⬐ nyargh

If the sha matched an existing one, would it be merged as part of the changeset, or just ignored?

⬐ sampo

If a sha matches, git won't fetch the object because it already has it.

⬐ mixologic

Repo access doens't stop people from injecting code into your repository. A pull request actually puts objects into your repo, but under a different ref than heads and tags.

1. Go to github, do a git clone 'repo' --mirror 2. cd to the bare repo.git and do a git show-ref and you will see all the pull requests in that repo. If any of those pull requests contained a duplicate hash, then in theory they would be colliding with your existing objects. But since git falls back to whatever was there first, I think it would be very challenging indeed to subvert a repo. You'd essentially have to find somebody who's forked a repo with the intention of submitting a PR, say, on a long running feature branch.

You could then submit your PR based off hashes in their repo before they do, which would probably mean your colliding object would get preference.

Its pretty far fetched, but the vector is non-zero.

⬐ E6300

It's easier than that. Someone could create a benign patch and a malicious patch that collides the hash. But what could they do with that?

For example, let's say it goes (letter##number represents the hashes):

State 1:

Real repo: R3 -> R2 -> R1 -> R0 (note: R3 is the head)

Benign PR: B1 -> B0 -> R1

Malicious PR: M1 -> M0 -> R1 (note: M0 = B0, but the contents are different)

State 2, after merging Benign PR:

Real repo: R4 -> R3 -> R2 -> R1 -> R0, R4 -> B1 -> B0 -> R1

If Malicious PR was merged now, Git would, I imagine, just believe that M1 is a commit that branched off of B0, since that's where the "pointer" is at.

So, yeah, what would this actually accomplish?

Linus Torvalds on git https://youtu.be/4XpnKHJAok8

OP actually pointed to an interesting reference[1] which briefly touches on the impact of pseudo-random number generation, amongst other things.

Diving a little bit deeper down the same rabbit hole, David A. Wheeler[2] (as he emphatically insists on being cited) also made note of threads with non-deterministic scheduling. Lots of notes on hardware-centric implications as well.

Definitely turns my perspective around on what it means to trust software. I suppose the effort is a proper graduation from masturbating[3] to safe sex, so to speak.

[1] https://reproducible-builds.org/docs/

[2] http://www.dwheeler.com/trusting-trust/

[3] https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...

I honestly don't believe it is an exaggeration. Take a look at this video for Linus's thoughts https://www.youtube.com/watch?v=4XpnKHJAok8

Linus Torvalds talk about git

https://www.youtube.com/watch?v=4XpnKHJAok8

⬐ c0achmcguirk

Was going to post the same one. Great talk!

> With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. But because blobs are usually compressed already, they usually don’t compress or diff well at all, and because they tend to be large, this means that your repository can bloat to really huge sizes really fast.

You can shallow clone a repository in git. This looks more like 'What should be the default mode for a source control : Centralized or Decentralized ?'. I think it should be decentralized since it requires more discipline.

> Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands.

This could simply mean that it is am amazing piece of technology that everyone loves to talk about it. It could also mean that it is a bit more complex, but that doesn't mean that the complexity is not worth the benefits.

> There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development

I think the point that was made was that the issue of commit access goes away : https://www.youtube.com/watch?v=4XpnKHJAok8&t=1139 ( actually that whole talk is pretty interesting ).

To be perfectly honest, most companies would do fine with subversion and a very good web based user interface. The simplicity and the advantage of not having to teach people set in their ways may work in its favor.

Some history from Linus himself https://www.youtube.com/watch?v=4XpnKHJAok8

A video of this wonderful Google tech talk is available on YouTube:

https://www.youtube.com/watch?v=4XpnKHJAok8

Agreed. As a high schooler I loved sourceforge. I would talk it up to people and I had a couple of projects that I put up there. I thought it was the best thing since sliced bread.

Then I saw that famous talk by Linus on git in 2007 (https://www.youtube.com/watch?v=4XpnKHJAok8). Since I had never managed to get SVN working properly for me git was awesome. No server software to install. By the time I wanted to put up another project on the web Github was a thing and I used that. I never looked back, I loved how it was about the code, not how many installer downloads you had.

That for me was the main problem with sourceforge. In the end it was a game (for the devs) to get the most downloads because that was how your projects were judged and ranked. The Github "game" is slightly better and there are multiple ways to play.

> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do.

It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8

> There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.

That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive?

In my company, we use git and there are access restrictions as to who can access and commit to our branches.

> Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.

..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise.

That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?

> 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: (https://www.youtube.com/watch?v=4XpnKHJAok8).

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.

⬐ recursive

> Git is really simple once you learn it.

Pretty much everything is simple once you learn it. That's what learning is. But git certainly doesn't go out of its way to make that process easy.

⬐ Dylan16807

>Pretty much everything is simple once you learn it.

I wouldn't say so. A lot of things are designed-by-committee implemented-by-the-lowest-bidder messes that are painful and complex even once you know how they work.

Git may have some weird design decisions but for the most part it's well-implemented and follows a simple conceptual model.

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 have to deal meaningless 'Fixed a typo' comments...

> There are numerous commands to do similar, overlapping but nonetheless different tasks. If for example you want to back up to earlier versions of code you can do git revert, git reset --hard, git reset --soft, git checkout -- <SHA>, git checkout <SHA> -- all of which do different but overlapping things.

git revert is not the same as git reset. git revert creates a new commit on top of the commit you want to revert. git reset move the HEAD. Totally different operations. git reset --hard, --soft, etc does the same thing, just differ how they handle the index and working tree, and once you understand I think it makes sense.

> A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches, making locating changes and reconstructing the history of changes extremely difficult.

If you stick to a simple workflow and rebase constantly, this is not a problem at all. Not everybody needs git-flow[2]. If you work on the same files with somebody, I think this will always be a problem, no matter what VCS you use, but with git there are a couple of merging strategies which can facilitate the process.

> Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files as well as snapshots of the entire project.

The SHA1s are for security. A commit's SHA is actually the SHA1 of that snapshot, so if you change any bit of that snapshot manually, git will complain about it[3]. It is basically that nobody can change code unnoticed!

> Lack of backward compatibility with RCS-style version control systems like Subversion.

I don't really understand what you mean here, but there is the command git svn, which is perfectly compatible with SVN. Recently I converted a whole SVN repository to Git without even losing one commit or message or anything... Also Git supports many more workflows[4], not just centralized.

> ... many obvious problems with Git.

Of course git is not perfect, but instead of ranting about it, you could learn it in a couple of days and work with it, becase many of us think it's pretty flexible and as simple as you want it to be. Actually, if you learn only two commands: add and commit, you can use Git, nobody stops you doing that if you find the other parts difficult.

[1]: https://guides.github.com/introduction/flow/index.html

[2]: http://nvie.com/posts/a-successful-git-branching-model/

[3]: http://youtu.be/4XpnKHJAok8?t=56m20s

[4]: https://www.atlassian.com/git/workflows#!workflow-centralize...

⬐ chx

> Would you rather see typos in a history?

Absolutely. Like, normal git log wouldn't show them only the branch merges but if you dig deeper then you'd see them. Or even allow to mark a commit as "superficial" (wikipedia has superficial edits). It is very easy to hide commits but once rebase destroys them it is impossible to see them even if needed.

Consider how scientific research works: you write down everything you do, preserve them and publish a book/paper/etc at the end. If it turns out you were not right then it's possible to peek at the notebooks later but if you were, noone ever will care.

⬐ Walkman

I never rebase commits which clearly shows how I got from point A to point B, even if I was wrong at the first time, but keeping typos in the log I think is silly.

⬐ NumberSix

@Walkman

I actually have been using Git extensively for 1 1/2 years. I have read the Pro Git book and many other sources cover to cover several times. I use magit with Emacs and gitk extensively. I gave up on the Android repo utility after it repeatedly goofed up the equivalents of git pull --rebase.

My complaints about Git are based on direct experience and watching others struggle with it.

Yes, I can and have set up Git in a very simple way not unlike an RCS project that avoids most of the issues that I discuss. No rebasing. Minimal use of branches, just a simple approximation of a development/production branch system. Nonetheless there are several problems with Git that still bit me such as the lack of sequential ids for files and the confusing terminology (staging areas, the index, etc.) and documentation.

For a better Git:

1. Clean up the documentation and man pages to remove the confusing terminology. Settle on one name for the "index" and so on.

2. Ditch rebasing.

3. Use sequential ids with a suffix of some sort for local changes. e.g. 1.2 on the master, 1.3.repo.branch or something like that for local changes. Keep the SHA, hide the SHA, but give users an easy intuitive way to access the SHA if needed.

1.1

1.2

1.3 \

1.4 1.4.myrepo.master

1.5 |

| /

1.6

1.7

I would guess there is some scheme like this in some other distributed version control system.

4. Simple checkin/checkout commands like RCS

Sincerely,

Bit by Git

⬐ e40

2. Ditch rebasing.

You really are completely clueless. Rebasing is invaluable for use on private branches that no one will ever see but the developer. It allows you to clean up your history before others see it.

EDIT: oh, and you can make a hook (like I did from day 1) that disallows non-fast-forward pushes to certain public repos.

This article brings back memories. Back in 2007, I had just watched Linus' presentation on Git at Google (http://www.youtube.com/watch?v=4XpnKHJAok8) 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.

This is a good one on version control:

http://www.youtube.com/watch?v=4XpnKHJAok8 (Linus' Git talk at Google)

And as far as the business of software, especially the internet, surveillance, trust, and marketing:

http://www.youtube.com/watch?v=m3NJ-Ow2Lvg (Bruce Schneier talk at Google shortly after Snowden revelations)

⬐ joeclark77

I think I saw that one by Linus on Youtube but didn't have time to watch it. I'm going to have this class use Git to submit all their work (project and otherwise). I've used it a lot for my own work, but never on a team project, so I will need something of a primer on how to do branching, merging, and so forth.

I understand there's a typical workflow in which you have 'master' for the releases, 'dev' for the latest working version, and feature branches are branched off 'dev'. If there's a good video on how to do that, it'd be ideal.

⬐ logn

I don't know of a video. But you should check out this project and its readme:

https://github.com/nvie/gitflow

edit: oh, the readme links to screen-casts! Also, I've worked on teams that require gitflow so I assume it's useful experience for students to have.

⬐ joeclark77

That link led me to another, which led to this original article on the git-flow model: http://nvie.com/posts/a-successful-git-branching-model/

Thanks! That's just what I was looking for.

During his speech at Google "[after reviewing the alternatives] the end results was I decided I can write something better than anything out there in two weeks. And I was right"

http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&...

⬐ read

Something's still not clear about his assumptions in that talk. He says "you just continue to work" and "you could do everything you would do" [if you were connected online]. But this is not true when it comes to integration of source control with issue-tracking.

If you integrate source control with issue-tracking, you start to want source code changes to correspond to issue numbers, and changes to be pushed if an issue is in a certain state or owned by a specific developer. But you can't get this information when you are offline without access to the issue-tracker.

Either there's a case for distributed issue-tracking too, which would give you that information, or issue-tracking being centralized pushes back on source control wanting to be distributed.

I wish this was addressed in Git's assumptions.

⬐ ithkuil

https://github.com/schacon/ticgit/wiki

YMMV

⬐ mtdewcmu

I've been mulling over issue tracking lately, since I hate Jira and all the other ones I've used. Wouldn't issues being in states and having owners violate the distributed model? Version control used to have file owners and locks, which is the same thing, and git broke from that.

⬐ modeless

Sounds like you want https://www.fossil-scm.org. Distributed version control with integrated wiki and bug tracking, from the creator of SQLite.

⬐ selectnull

Another option is Veracity by Sourcegear. http://veracity-scm.com/

⬐ hrjet

Their DVCS comparison page is very informative: http://veracity-scm.com/compare/

⬐ reledi

According to his recent save format post [1], he spends a lot of time thinking about something before he starts prototyping.

> So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding.

So two weeks seems reasonable to me, especially if he built a prototype first. (Did he?)

1: https://plus.google.com/102150693225130002912/posts/X2XVf9Q7...

⬐ pags

Isn't he blurring the line between "commit" meaning creating a state you can roll back to (in all version control systems), and "commit" meaning pushing to the "official" code base in a non-distributed system? In other words, some issues with non-distributed systems that he highlights (having to keep an elite group deemed smart enough to integrate changes, for example) still exist when pushing to a consensus "official" instance of a distributed repo.

⬐ richardwhiuk

Probably because those two actions are identical in CVS, SVN etc, which most people at the talk were familiar with, unlike the commit and push states in a DVCS (hg, git, bzr etc).

⬐ jordigh

His language is pretty muddled in this talk. It's clear he didn't really spend a lot of time thinking about precise and unambiguous language for all of the things he was talking about. He also seems to conflate "branch" and "clone".

This muddled language later turned into a muddled UI that was supposed to get cleaned up, but never did.

⬐ kdd44

In what way does git conflate "branch" and "clone"?

⬐ pags

I can't help but think that he was conveniently leaving out details that give the entire story - clearly he thinks the audience are unintelligent sheep, so surely they'll take him at his word, right?

⬐ zenbowman

Yeah, that was a great talk. I highly recommend people watch it.

He was definitely right about that, what I like about Linus is he really does seem to prefer to do things in as concrete and simple a way as possible instead of getting mired in abstractions.

⬐ jonalmeida

He mentions that git wasn't half as good if it wasn't for the help he got after his initial creation that made it cleaner and better.

⬐ jordigh

Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g. for blame and clone operations) and actually was conceived with a UI from the beginning.

I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.

⬐ stiff

Every occasion is good to start a flame war, isn't it?

⬐ None

None

⬐ huhtenberg

(3) C implementation

There's a strong aversion of using tools done in Python outside of Python community. It is irrational, but it being an inherently interpreted language puts it into the same perception bucket as Perl and who'd want to use a control system written in Perl?

⬐ dima55

Dude, python IS in the same bucket as perl. The list of pros and cons when compared to C is identical.

⬐ annnnd

There is one difference - you need an external tool to properly obfuscate Python source code. :)

⬐ huhtenberg

Shhh... don't tell HN.

⬐ codemac

Well, you're also missing some reasons:

- git has an 'email' centric workflow

- The index with git (git add -i) awesome for people doing patch maintenance

- the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase.

It's almost like those reasons follow the linux workflow.. almost perfectly.

⬐ jordigh

Sigh, I wish people would actually know about Mercurial. It was created for the exact same reason as git, at the same time, and is also intended for kernel development. In particular,

- Mercurial also has an email-centric workflow, look at its mailing list: http://mercurial.markmail.org/search/?q=#query:+page:1+mid:p...

- The staging area can be achieved in hg in several ways, or it can be avoided as desired. One easy way is to just pick apart your commit with hg (c)record --amend and just keep adding to your commit as necessary.

- Rebasing has also been available in hg forever (and wasn't available in git from the beginning). We also have some really interesting changes brewing for rebasing in Mercurial: https://www.youtube.com/watch?v=4OlDm3akbqg

These ideas in hg were all for following the Linux workflow too.

Nothing against git, but it's important to not deify Linus as if he were a unique genius. He has his flaws, and so does the software that he's responsible for.

⬐ dredmorbius

I've used both.

Mercurial beat git past the starting gates, but git has the advantage of being used on a very widely used, widely developed, immensely high profile project. While Hg has its own commendable set of projects, git has simply won the mindshare battle.

Could be worse: there's arch and bzr and probably some others.

Hell, even GNU/EFF are looking to ditch their own VCS in favor of git from what I understand.

⬐ jordigh

Yes, that's true git's main advantage is how widespread it is.

GNU Emacs decided to switch from bzr to git, but GNU as a whole doesn't have a recommended VCS yet. In GNU Octave we will keep using hg. I don't think the EFF is too public about which VCS they use.

⬐ dredmorbius

I meant to type "GNU/FSF". I thought I caught myself and corrected the "EFF" bit. I knew I was going to write that. And damnit, I did.

But yes, I meant "FSF", not "EFF".

⬐ bronson

Mercurial went a long way down the "never modify history!" road (i.e. never rebase). Turns out that attitude, while theoretically pure, isn't very pragmatic. There are lots of valid reasons for rebasing.

Hg eventually came around but, for me, the damage had been done. It's the second biggest reason I went with git.

(The biggest, of course, is you use git if you want to interact with kernel devs. But lots of kernel devs hated git in 2005/2006. Mercurial had a reasonably big window of opportunity... all imo, fwiw)

⬐ read

- git has an 'email' centric workflow

That's a good observation. Git seems to assume its distributed issue-tracker is email.

⬐ zurn

Those aren't big things outside Linux.

⬐ throwaway7767

Email centric workflows are used for lots of projects other than the linux kernel.

My workflow for a lot of the projects I contribute to is something like:

edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email

⬐ Argorak

> - git has an 'email' centric workflow

Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches.

When setting up my email setup, I consulted the underlying Perl script more than the docs :(.

Her is great video from Google tech Talk starring Linus Torvalds (about Git): http://youtu.be/4XpnKHJAok8. Note - Linus uses some strong language.

⬐ JetSpiegel

> Note - Linus uses some strong language.

That's a bit redundant.

⬐ oneandoneis2

"Linus says things" would have been enough :)

⬐ zhaphod

How liberating it must feel to him to not give a damn about what anyone thinks about what he says. Good for him.

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 GIT is better than SVN. The crucial point to me, though, is that it is so much better. So much better that it is worth the effor to build and worth the effort of the community to switch.

[0] https://www.youtube.com/watch?v=4XpnKHJAok8 [1] https://www.youtube.com/watch?v=-F-3E8pyjFo

⬐ isxek

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.

Having experienced the workflow they learned from using another DVCS (Bitkeeper) probably also influenced his decision at the time.

- why is the sky blue?

- why do birds sing in the morning?

here's why from G-O-D itself: http://www.youtube.com/watch?v=4XpnKHJAok8

⬐ atmosx

I was curious to see if anyone posted this already :-)

Awesome talk by my favorite programmer :-P

⬐ None

None

I still think the absolute best way to learn git is to watch the talk Linus gave at Google some years back - http://www.youtube.com/watch?v=4XpnKHJAok8 - just understanding the underlying concepts makes the rest of it easy to grasp.

⬐ isxek

If nothing else, you can at least see what a Google talk with Linus making more light-hearted remarks looks like, compared to the LKML-related posts discussed months ago.

Don't worry about needing to catch up. Stuff is moving so fast these days, you're always working with something new. Everyone is in a continual update mode so it's not like you have 10 years of catching up to do. Tech has turned over a 10 times since then. You could say 10 years and 2 years are functionally equivalent from a new tech point of view.

And don't worry about corps and recruiters. Focus on a problem you want to solve, and update your skills in the context of learning what you need to know to solve that problem. If you can leverage your industry experience in the problem domain, even better.

Data is driving everything so developing a data analysis/machine learning skillset will put you into any industry you want. Professor Yaser Abu-Mostafa's "Learning From Data" is a gem of a course that helps you see the physics underpinning the learning (metaphorically of course -- ML is mostly vectors, matrices, linear algebra and such). The course videos are online for free (http://work.caltech.edu/telecourse.html), and you can get the corresponding book on Amazon -- it's short (http://www.amazon.com/Learning-From-Data-Yaser-Abu-Mostafa/d...).

Python is a good general purpose language for getting back in the groove. It's used for everything, from server-side scripting to Web dev to machine learning, and everywhere in between. "Coding the Matrix" (https://www.coursera.org/course/matrix, http://codingthematrix.com/) is an online course by Prof Philip Klein that teaches you linear algebra in Python so it pairs well with "Learning from Data".

Clojure (http://clojure.org/) and Go (http://golang.org/) are two emerging languages. Both are elegantly designed with good concurrency models (concurrency is becoming increasingly important in the multicore world). Rich Hickey is the author Clojure -- watch his talks to understand the philosophy behind the design (http://www.infoq.com/author/Rich-Hickey). "Simple Made Easy" (http://www.infoq.com/presentations/Simple-Made-Easy) is one of those talks everyone should see. It will change the way you think.

Knowing your way around a cloud platform is essential these days. Amazon Web Services (AWS) has ruled the space for some time, but last year Google opened its gates (https://cloud.google.com/). Its high-performance cloud platform is based on Google search, and learning how to rev its engines will be a valuable thing. Relative few have had time to explore its depths so it's a platform you could jump from.

Hadoop MapReduce (https://hadoop.apache.org/, http://www.cloudera.com, http://hortonworks.com/) has been the dominant data processing framework the last few years, and Hadoop has become almost synonymous with the term "Big Data". Hadoop is like the Big Data operating system, and true to its name, Hadoop is big and bulky and slow. However, there is a new framework on the scene that's true to its name. Spark (http://spark.incubator.apache.org/) is small and nimble and fast. Spark is part of the Berkeley Data Analytics Stack (BDAS - https://amplab.cs.berkeley.edu/software/), and it will likely emerge as Hadoop's successor (see last week's thread -- https://news.ycombinator.com/item?id=6466222).

ElasticSearch (http://www.elasticsearch.org/) is a good to know. Paired with Kibana (http://www.elasticsearch.org/overview/kibana/) and LogStash (http://www.elasticsearch.org/overview/logstash/), it's morphed into a multipurpose analytics platform you can use in 100 different ways.

Databases abound. There's a bazillion new databases and new ones keep popping up for increasingly specialized use cases. Cassandra (https://cassandra.apache.org), Datomic (http://www.cognitect.com/), and Titan (http://thinkaurelius.github.io/titan/) to name a few (http://nosql-database.org/). Redis (http://redis.io/) is a Swiss Army knife you can apply anywhere, and it's simple to use -- you'll want it on your belt.

If you're doing Web work and front-end stuff, JavaScript is a must. AngularJS (http://angularjs.org/) and ClojureScript (https://github.com/clojure/clojurescript) are two of the most interersting developments.

Oh, and you'll need to know Git (http://git-scm.com, https://github.com). See Linus' talk at Google to get the gist (https://www.youtube.com/watch?v=4XpnKHJAok8 :-).

As you can see, the opportunities for learning emerging tech are overflowing, and what's cool is the ways you can apply it are boundless. Make something. Be creative. Follow your interests wherever they lead because you'll have no trouble catching the next wave from any path you choose.

⬐ jnardiello

Thanks for this. Quite incredibly valuable comment. This is why i love HN.

⬐ christiangenco

I'm a web developer that considers myself "up-to-date" but there was quite a bit in there that I need to read up on (notably Hadoop and ElasticSearch). Thanks for the links!

I'd also recommend, as some alternatives:

* Ruby as an alternative "general purpose language"

* Mongo as an alternative swiss army database

* Backbone + Marionette as an alternative front-end JS framework

* CoffeeScript as a better Javascript syntax

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: https://www.youtube.com/watch?v=4XpnKHJAok8

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.

⬐ lucb1e

I lasted eight minutes watching the video. He just rambles about how screwed everything is and how right he is.

⬐ qwerta

You would see it differently, if you would know CVS :-)

⬐ jeltz

Interesting how different people can see the same thing. To me Linus seems to be mostly pleasant during that talk and to the point. I have heard ranty talks and this is not one of them.

I assume it must be cultural difference, since I also checked with my colleagues and they do not think Linus was rude either during that talk.

I think he means the git talk at google [1] where he defines a few things at the start, among them "wrong, stupid: people who disagree with linus" and states that therefore, during the talk, by definition everyone who disagrees with him is stupid and butt-ugly.

[1] http://www.youtube.com/watch?feature=player_detailpage&v=4Xp...

⬐ PavlovsCat

Which is the exact opposite of doing it in person though, it's being all cute and funny about it. Actually doing that in person would look and feel radically different.

⬐ beachstartup

i'm 100% certain linus is not being cute, or funny. he means it when he says certain people are stupid.

⬐ PavlovsCat

Compared to the stuff he types into his keyboard it's still lame, and being cute and funny in comparison.

Also, stupid is relative anyway. Who isn't stupid? Is Linus actually that stupid that he thinks he isn't stupid? And if he is, what kind of weight does he think this insult carries out of his mouth? Stuff gets tricky real quick like that.

Really? In when Linus did his talk about git for Google Tech Talks, he explained that the reason they parted ways because many of the linux developers were taking issue to working in a non-libre environment, I seem to recall...

hmmm

here's the link: https://www.youtube.com/watch?v=4XpnKHJAok8

⬐ pyre

BitKeeper was non-libre for a long time, but they dropped the free-to-the-community version[1] which forced the move. Linus drew criticism for a long time over the usage of a non-libre version control system for the Linux kernel.

[1] http://en.wikipedia.org/wiki/Bitkeeper#Pricing_change

⬐ mpyne

If no one has ever read the backstory behind this it's actually a good tale.

There was more to the issue than BK simply deciding to drop the free version. The short story behind that one of the Samba authors helped force Free Software along in more ways than one!

⬐ GhotiFish

I went and tried to find some information. Definitely worth a read! Thanks. Actually. I'm gonna post it as a story.

http://www.quora.com/What-are-some-well-written-accounts-of-...

Summary of the links shared here:

http://blip.tv/clojure/michael-fogus-the-macronomicon-597023...

http://blog.fogus.me/2011/11/15/the-macronomicon-slides/

http://boingboing.net/2011/12/28/linguistics-turing-complete...

http://businessofsoftware.org/2010/06/don-norman-at-business...

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-R...

http://en.wikipedia.org/wiki/Leonard_Susskind

http://en.wikipedia.org/wiki/Sketchpad

http://en.wikipedia.org/wiki/The_Mother_of_All_Demos

http://io9.com/watch-a-series-of-seven-brilliant-lectures-by...

http://libarynth.org/selfgol

http://mollyrocket.com/9438

https://github.com/PharkMillups/killer-talks

http://skillsmatter.com/podcast/java-jee/radical-simplicity/...

http://stufftohelpyouout.blogspot.com/2009/07/great-talk-on-...

https://www.destroyallsoftware.com/talks/wat

https://www.youtube.com/watch?v=0JXhJyTo5V8

https://www.youtube.com/watch?v=0SARbwvhupQ

https://www.youtube.com/watch?v=3kEfedtQVOY

https://www.youtube.com/watch?v=bx3KuE7UjGA

https://www.youtube.com/watch?v=EGeN2IC7N0Q

https://www.youtube.com/watch?v=o9pEzgHorH0

https://www.youtube.com/watch?v=oKg1hTOQXoY

https://www.youtube.com/watch?v=RlkCdM_f3p4

https://www.youtube.com/watch?v=TgmA48fILq8

https://www.youtube.com/watch?v=yL_-1d9OSdk

https://www.youtube.com/watch?v=ZTC_RxWN_xo

http://vimeo.com/10260548

http://vimeo.com/36579366

http://vimeo.com/5047563

http://vimeo.com/7088524

http://vimeo.com/9270320

http://vpri.org/html/writings.php

http://www.confreaks.com/videos/1071-cascadiaruby2012-therap...

http://www.confreaks.com/videos/759-rubymidwest2011-keynote-...

http://www.dailymotion.com/video/xf88b5_jean-pierre-serre-wr...

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

http://www.infoq.com/presentations/click-crash-course-modern...

http://www.infoq.com/presentations/miniKanren

http://www.infoq.com/presentations/Simple-Made-Easy

http://www.infoq.com/presentations/Thinking-Parallel-Program...

http://www.infoq.com/presentations/Value-Identity-State-Rich...

http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...

http://www.mvcconf.com/videos

http://www.slideshare.net/fogus/the-macronomicon-10171952

http://www.slideshare.net/sriprasanna/introduction-to-cluste...

http://www.tele-task.de/archive/lecture/overview/5819/

http://www.tele-task.de/archive/video/flash/14029/

http://www.w3.org/DesignIssues/Principles.html

http://www.youtube.com/watch?v=4LG-RtcSYUQ

http://www.youtube.com/watch?v=4XpnKHJAok8

http://www.youtube.com/watch?v=5WXYw4J4QOU

http://www.youtube.com/watch?v=a1zDuOPkMSw

http://www.youtube.com/watch?v=aAb7hSCtvGw

http://www.youtube.com/watch?v=agw-wlHGi0E

http://www.youtube.com/watch?v=_ahvzDzKdB0

http://www.youtube.com/watch?v=at7viw2KXak

http://www.youtube.com/watch?v=bx3KuE7UjGA

http://www.youtube.com/watch?v=cidchWg74Y4

http://www.youtube.com/watch?v=EjaGktVQdNg

http://www.youtube.com/watch?v=et8xNAc2ic8

http://www.youtube.com/watch?v=hQVTIJBZook

http://www.youtube.com/watch?v=HxaD_trXwRE

http://www.youtube.com/watch?v=j3mhkYbznBk

http://www.youtube.com/watch?v=KTJs-0EInW8

http://www.youtube.com/watch?v=kXEgk1Hdze0

http://www.youtube.com/watch?v=M7kEpw1tn50

http://www.youtube.com/watch?v=mOZqRJzE8xg

http://www.youtube.com/watch?v=neI_Pj558CY

http://www.youtube.com/watch?v=nG66hIhUdEU

http://www.youtube.com/watch?v=NGFhc8R_uO4

http://www.youtube.com/watch?v=Nii1n8PYLrc

http://www.youtube.com/watch?v=NP9AIUT9nos

http://www.youtube.com/watch?v=OB-bdWKwXsU&amp;playnext=...

http://www.youtube.com/watch?v=oCZMoY3q2uM

http://www.youtube.com/watch?v=oKg1hTOQXoY

http://www.youtube.com/watch?v=Own-89vxYF8

http://www.youtube.com/watch?v=PUv66718DII

http://www.youtube.com/watch?v=qlzM3zcd-lk

http://www.youtube.com/watch?v=tx082gDwGcM

http://www.youtube.com/watch?v=v7nfN4bOOQI

http://www.youtube.com/watch?v=Vt8jyPqsmxE

http://www.youtube.com/watch?v=vUf75_MlOnw

http://www.youtube.com/watch?v=yJDv-zdhzMY

http://www.youtube.com/watch?v=yjPBkvYh-ss

http://www.youtube.com/watch?v=YX3iRjKj7C0

http://www.youtube.com/watch?v=ZAf9HK16F-A

http://www.youtube.com/watch?v=ZDR433b0HJY

http://youtu.be/lQAV3bPOYHo

http://yuiblog.com/crockford/

⬐ ricardobeat

And here are them with titles + thumbnails:

http://bl.ocks.org/ricardobeat/raw/5343140/

⬐ waqas-

how awesome are you? thanks

⬐ Expez

Thank you so much for this!

⬐ X4

This is cool :) Btw. the first link was somehow (re)moved. The blip.tv link is now: http://www.youtube.com/watch?v=0JXhJyTo5V8

Single best is difficult, here are some favourites of mine:

"You and your research" by Richard Hamming:

http://www.youtube.com/watch?v=a1zDuOPkMSw

"How to design a good API and why it matters" by Joschua Bloch:

http://www.youtube.com/watch?v=aAb7hSCtvGw

Google TechTalk on Git by Linus Torvalds:

http://www.youtube.com/watch?v=4XpnKHJAok8

All talks ever given by Alan Kay, for example:

http://www.youtube.com/watch?v=oKg1hTOQXoY

⬐ stblack

Double thumbs-up to Google TechTalk on Git by Linus Torvalds.

I think the talk you are referring to is tech talk he gave at google:

http://www.youtube.com/watch?v=4XpnKHJAok8

He means stupid as in simple, unaware of things it does not need to know. Stupidity and ignorance in software is high praise and it's very difficult to achieve.

See: http://en.wikipedia.org/wiki/Information_hiding

That style is just linus' way. It comes across as a lot more aggressive on screen than in person. To get a better sense of him, I'd recommend watching this talk he gave evangelising git at google back in 2007. It's pretty entertaining, and very educational on the issues facing VCS designers.

http://www.youtube.com/watch?v=4XpnKHJAok8

To a certain extent, if you can knock git together in a couple of weeks you get a free pass to talk however you want, as long as you don't hurt anyone.

⬐ mmariani

Ouch! No heed to be harsh. I certainly appreciate Linus's work. Kudos to him! I understood his point on the stupidity thing. It even took some laughs out of me. And that's the reason I posted that, so other people could too.

I don't mean to start a flamewar on scm, really. But I think git is overly complicated, and I believe I'm not alone on that.

Anyway, don't take things too seriously and have a good one!

PS: You gave a great idea. I should email Linus and offer to pay him some beers. That sure will be a great talk. Thanks mate!

⬐ JonnieCache

Sorry, really didn't mean to be mean whatsoever. It's hard to convey tone in internet comments :)

His comment was more general:

"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly, so keep that in mind."

http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu...

Don't forget SVN: http://www.youtube.com/watch?v=4XpnKHJAok8

i think this is the place to remind of torvalds git talk http://www.youtube.com/watch?v=4XpnKHJAok8

A great speech @ Google on a subject directly apropos of pg's start-up spiel:

http://www.youtube.com/watch?v=IyNPeTn8fpo

Another awesome speech from Google's tech talk series (it takes a little bit of tyrant to pull this off, tho):

http://www.youtube.com/watch?v=4XpnKHJAok8

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: http://www.youtube.com/watch?v=4XpnKHJAok8

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

http://www.youtube.com/watch?v=4XpnKHJAok8#t=17m4s

Here is a talk by linus about git, although it isn't a tutorial.

http://www.youtube.com/watch?v=4XpnKHJAok8

Linux kernel development was managed with tarballs and patches for the first 10 years, until BitKeeper was selected in 2002, then of course Git in 2005.

Source: http://en.wikipedia.org/wiki/Linux_kernel#Revision_control Also see Linus Torvalds' Google Tech Talk on Git starting around 2:45 http://www.youtube.com/watch?v=4XpnKHJAok8

Watch this video and you will become enlightened as to why this is the case:

[Linus Torvalds on Git] http://www.youtube.com/watch?v=4XpnKHJAok8

You should check out Linus' tech talk at Google about Git. Not only is Linus a really good speaker, he explains how a DVCS like git changes the workflow when it comes to managing the 'main' repository.

Spoiler: He has a 'circle of trust'. He pulls and merges commits from people he thinks are really smart and those people in turn pull and merge from people they think are smart.

http://www.youtube.com/watch?v=4XpnKHJAok8

Semi-related: a video of Linus giving a talk on Git at Google http://www.youtube.com/watch?v=4XpnKHJAok8

Watch for the bit where he goes:

"What are you guys using?

pause

Perforce?

longer pause

I'm ... sorry."

⬐ ableal

Take that with a grain of salt.

Linus is snug as a bug in a rug, having solved his own problem of dealing with e-mailed patches. This also works for many coders with similar work-flows.

But, for work-flows with binaries (documents, images, executables, etc.) Perforce looks better, if you read through the comments in the LWN piece. For instance:

[git, problems with binaries] this has been documented several times, but it seems to be in the category of 'interesting problem, we should do something about that someday, but not a priority' right now

P.S. a couple of months ago, in another HN discussion, stevelosh kindly contributed a link about the bfiles extension for Mercurial: http://mercurial.selenic.com/wiki/BfilesExtension

⬐ shadowsun7

The article above talks about Google's work on the Linux kernel, something that is managed competently with Git outside of the company.

Granted, Linus's comment is a sweeping statement (as most snarky comments tend to be) but in this context, Perforce seems woefully inadequate for managing Google's kernel work.

Well, Paul has a similar "quirk". He uses two PCs. Everyone's seen this by now: http://www.paulgraham.com/distraction.html Also Linus disliked using Google's net connection for his Git talk. Here's one relevant excerpt:

When I am here (Google) I cannot read my e-mails because my e-mail goes onto my machine and the only way I can get into that machine is when I am physically on that network. So maybe I am a cuckoo, maybe I am a bit crazy, and I care about security more than most people do. https://git.wiki.kernel.org/index.php/LinusTalk200705Transcr...

In another part he was about to demonstrates a kernel diff, but stops when he realized he's disconnected from Google's net. Here's the talk: http://www.youtube.com/watch?v=4XpnKHJAok8 One of my favorites; a classic. And I don't even do software.

This is effectively a summary of his Google Tech Talk on git.

http://www.youtube.com/watch?v=4XpnKHJAok8

⬐ memoryfault

Man, he really hates CVS.

⬐ oomkiller

I'm too young to have used CVS, but I really hate SVN compared to Git :)

⬐ Groxx

Having dealt even superficially with a large CVS repository... don't we all? SVN is at least more stable.

⬐ malkia

We have used long time (2001) ago CVS as repository for one of our games (NHL2K2), and one of the programmers used a specific way of commenting his code. One day, that form of commenting messed up somehow the diff information the .CVS - it was easy to fix (we manually fixed the problem, it was some kind of +, - that got wrong, or something like that).

Once we moved to P4 it was a relief, and still is. And nothing stops you from using P4 with git/mercurial or others.

P4 is great, but sometimes I need to submit more than one changelists (set of files) with the same file, but different bugfixes.

⬐ wallflower

This classic essay always makes me chuckle. Especially when svn branching or mergeinfo goes awry

"If Version Control Systems were Airlines"

CVS:

"Watch out for layovers, though. It can take hours to merge new passengers into the formation properly, and it might take several attempts to take off afterwards."

SVN:

"At checkin time at the gate, if more than one person arrives with a copy of the same ticket, they are ushered into the “merging room” and each person is given a brick. The door is closed, something magical occurs, and the one person that emerges still able to walk is allowed to board the plane."

http://changelog.complete.org/archives/698-if-version-contro...

⬐ TrevorBurnham

This is a video from 2007 that's over an hour long. Executive summary, someone, please?

⬐ eccp

Summary: Linus hates CVS and, by extension, SVN. Talks about the importance of distributed development and pains of the centralized model. You can work offline. On centralized, trivial decisions can't be taken because they pollute the central repository and leads to bad practices. Creating branches is not the main issue, merging FAST is. Git performs/scales well, 22K files on the Linux kernel repo, about 4 merges a day for 2 years since being tracked with Git. Mercurial is good, but Git is better. Git uses SHA-1 hashes for the full history, brings security against attacks and RAM/disk corruption.

⬐ petercooper

FWIW, this is the video that was cited by Chris Wanstrath (of GitHub) as what got him into Git (on, I believe, his episode of the Changelog Show - http://changelogshow.com/105/2274-episode-0-1-0-chris-wanstr...). It was a video that caught my attention at the time too, but I didn't get on the Git train for at least a year or two after.. sheepish look

For me, it was watching Linus' Google talk on git, and then reading some tutorials, and then just doing it.

    Linus: http://www.youtube.com/watch?v=4XpnKHJAok8
    GitReady: http://gitready.com/
    Pro Git: http://progit.org/book/
    A short little bit about git's internal model: http://eagain.net/articles/git-for-computer-scientists/
    GitHub's Git Cheat Sheet: http://github.com/guides/git-cheat-sheet
    A successful git branching model. gorgeous workflow and pictures. http://nvie.com/archives/323

Also, if you have any questions, feel free to email me. The only reason someone should be using SVN now is if there are institutional reasons or if you use lots of large binary files. I'd rather you send me an email about something that seems hard than give up and use an inferior tool. I'm not an absolute git master, but I've ended up explaining it to most of my classmates, so I've given that explanation a few times already.

⬐ nollidge

At work we have LOTS of large binary files, yes. Static dependencies in C#. But I'll give it a go for personal projects.

Thanks!

⬐ steveklabnik

No problem. It's something that's being worked on, just merging them becomes a pain. If your dependencies are truly static, in the sense that you're not modifying them or updating them often, it shouldn't be a big deal. Usually it's large images or other 'asset' type stuff that causes a bloated repo.

> But the truth is, the answer to that is not much.

This claim may sound like truthful only if one never used git indeed.

EDIT: I think I should expand this. There is what I would miss if git is taken away from me, in no particular order:

Speed, speed, speed. Operations which SVN performs over network (and not in the most efficient way) git performs locally and it's blazingly fast.

Ease of branching and merging.

Local branches, squash commits.

Rebase.

Staging area.

Stash.

Having entire history at my fingertips and not having single point of failure which SVN central server is. The fact that entire history in git often takes less space than single checkout of SVN is a nice bonus.

Not having each and every directory of my project littered with .svn

Github.

There is more, of course.

I was kind of Subversion fan when I first saw Linus talk on git (http://www.youtube.com/watch?v=4XpnKHJAok8 ) and I did not like it at all. Then I did try git and saw the light :) I am still using SVN, but only because I have to. Now it looks dated (mature?), slow, clunky and fragile.

Absolutely as soon as you start working with other people you will need this knowledge. I wouldn't learn SVN because you can interact with SVN via Git. (git-svn). To get startet:

Git on Windows, how to install and use it (or see below for Tortoise git)

http://www.gitcasts.com/posts/git-on-windows

Mov: http://media.gitcasts.com/c10-windows-git.mov.zip

If you use the Git GUI from Msysgit to clone a repo please use the following credentials: ...

Tortoise Git is a easy solution which is thought to integrate into e.g. Explorer etc. Please see here for details:

http://code.google.com/p/tortoisegit/ (first install msysgit then this..)

Linus Torvalds on Git (a more detailed introduction) http://www.youtube.com/watch?v=4XpnKHJAok8

Git usage: ----------

Most interesting is for git is that "Branching" is very cheap. This means that if you want to implement feature X you just "branch" the repository (e.g. local or remote) and don't affect the main branch until you want to merge your code back into main.

Cloning: ---------

1.) Open e.g. Git Bash

2.) Go to the folder where you want to store the repository

3.) git clone ssh://IP:PORT/REPONAME.git TARGETDIR

4.) It will ask you for your ssh key. (please see the above video (.mov) for details).

Later then you can test things by just changing something slightly and recommiting it, e.g.

1.) cd TARGET

2.) vi README

    # ---> .... changed something

3.) git add *

4.) git commit

    # --> vi will pop up and you type e.g. one line "- 

Added some more

    # details to the README file how to do XYZ."
  
    # This can also be done on the commandline by:

    git commit -m "<YOUR MESSAGE HERE>"

5.) git push

    This will push back your changes to the master repository.

Have fun !

Linus was making fun of SVN in his talk ( http://www.youtube.com/watch?v=4XpnKHJAok8 ). One of his point was, that SVN chose the wrong way right from the start and there is no way to have "CVS done right" because CVS is hopeless by design.

⬐ absconditus

CVS may have had serious flaws, but I find Linus' original revision control practices to be less than optimal:

"The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems.

In 2002, Linux kernel development switched to BitKeeper, a SCM system which satisfied Linus Torvalds' technical requirements."

Nearly a decade without a revision control system?

http://en.wikipedia.org/wiki/Linux_kernel#Revision_control

⬐ solutionyogi

In Linus' git talk, he says that he finds creating different tarballs is much better version control than using CVS.

⬐ ankhmoop

If you compare granularity of tracking and utility of historical version control across different projects of that era, such as FreeBSD vs. Linux, I think you'll find that Linus' position is clearly false.

Disclaimer: I use Git for my own stuff and as an svn client at work.

But I wonder if Git's author's boorish-yet-sort-of-amusing behavior when invited to speak at Google a couple of years ago may have also quietly weighed on the decision some:

http://www.youtube.com/watch?v=4XpnKHJAok8

One of the things I thought was interesting about this post was when he said "And what they find there is someone who doesn't seem to get it" (regarding Linus speaking on Subversion in his talk at google: http://www.youtube.com/watch?v=4XpnKHJAok8 ).

When I watched the talk initially, I had the impression that what made Linus' talk tip from "I don't think this is the right way of doing things" to "I think SVN is a pile of crap" wasn't so much on the history model (DAG vs line), but SVN's implementation. Specifically, I was thinking about how the base revisions are stored locally (with the .svn folders in each versioned control folder, which git resolves much more efficiently), the poor rename support etc. It's been a while since I saw that talk though, so it may well be that he was indeed criticising the Line model in general (and I can see how the line model doesn't fit in with his workflow at all.)

You might be interested in this talk Torvalds gave at Google where he talks about how Git came about:

http://www.youtube.com/watch?v=4XpnKHJAok8

This talk by Linus Torvalds was what got me excited about Git: http://www.youtube.com/watch?v=4XpnKHJAok8

http://www.youtube.com/watch?v=4XpnKHJAok8

Watch the entire thing.

Not all of Google (yet), but there has been some significant lobbying for the use of git inside Google in the past by Linus himself.

http://www.youtube.com/watch?v=4XpnKHJAok8 (Google Tech Talk)

If you want to learn more about git and the motivation behind it, then I really recommend watching the linked video. I find it quite entertaining.

⬐ ComputerGuru

Yeah, because Linus is really impartial on the matter ;-)

git is hot why would you want to switch back.

Tech Talk: Linus Torvalds on git http://www.youtube.com/watch?v=4XpnKHJAok8

you can run git on windows too... http://code.google.com/p/msysgit/

that project is awesome (just started trying it today) but it includes a full unix cli including bash and coreutils.

⬐ wfarr

... it's an April Fools joke.

⬐ xenoterracide

ah... I hate april fools. I'm always the fool. regardless. I posted good info. So why should I get modded down?

For a talk (partially) dedicated to the vesion control system and why it sucks:

http://www.youtube.com/watch?v=4XpnKHJAok8

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.

http://www.youtube.com/watch?v=4XpnKHJAok8

⬐ jsnx

Do you use either one?

Hear Linus Torvalds talk about Git:

http://www.youtube.com/watch?v=4XpnKHJAok8

Do people who use the word "f-bomb" invariably turn out to have no sense of humor? Or is it just me?

Am I the only one who actually laughs when a guy puts up a slide with a dictionary definition of the word "arrogant", admits that the definition fits his personality, and then (a few slides later) responds to other programmers' criticisms of his framework with a two-word slide: "f__k you"? Is the concept of "setup" followed by "punch line" really so obscure? Is the word "f__k" really so disturbing to your delicate insides?

Am I the only one who is amused by these lines from Linus Torvalds' git talk (http://www.youtube.com/watch?v=4XpnKHJAok8):

"If you actually like using CVS, you shouldn't be here... you should be in some mental institution, somewhere else."

"Git is so much better than everything else... because my brain did not rot from years and years of thinking CVS did something sane. Not everyone agreed with me... they were ugly and stupid."

"I decided I could write something better than any [source code management system] out there in two weeks... and I was right."

... despite the fact that Linus is (technically) insulting me and every programmer I've ever known?

And am I the only one in the world who saw the title of DHH's critique of the mobile web app ("You're not on a f__king plane!") and laughed out loud, because it was an obvious reference to Samuel "L" Jackson's famous line from "Snakes on a Plane"?

(I guess the reference would have been clearer if DHH had written "You're not reading this Motherf___ing Post on a Motherf___ing Plane", but somehow I doubt that such a title would have appeased the "f-bomb" crowd. Quite the contrary.)

I'd love to read more critiques of DHH (and Torvalds, and PG for that matter) that actually engage his ideas, and fewer tone-deaf, catty complaints about his attitude, his vocabulary, and the fact that not all of his apps are legendary success stories. If his work is so "anti-user", would you please give me some examples of similar apps that do a better job, and explain why you think so? If the web app which works offline is such an amazingly good idea, would you please tell me which ones you use, or perhaps build one and then sell it to me?

⬐ fnord123

What is "f-bomb"?

⬐ adnam

It's an americanism.

⬐ scw

http://en.wikipedia.org/wiki/F-bomb

⬐ felipe

The problem is that David is not Linus nor PG, so that sounds awfully arrogant coming from him.

The other problem is that David's ideas are not really "his ideas". He simply recycled XP and Agile concepts from the 90s. I for one prefer to read the originals (Kent Beck, Martin Fowler, Ron Jeffries, etc...)

⬐ palish

Creativity is knowing how to hide your sources.

But anyway, a Railsite told me the other day that what he loves about Rails is that it's not especially new, conceptually. It's a series of mdthodologies that work great.

⬐ mechanical_fish

Do you think that PG invented Lisp, or the software startup, or angel investing? Do you think that Linus Torvalds invented Unix?

Yes, Rails is the instantiation of a bunch of XP and Agile concepts. But here's the thing: concepts don't serve Web pages. Code serves Web pages. And even Martin Fowler doesn't take the time to write all his own code from scratch.

I don't respect DHH because his ideas are original. I respect him because he can convince thousands of programmers around the world to work together. That is not an easy trick - there's a reason why it has been compared to herding cats.

http://www.youtube.com/watch?v=4XpnKHJAok8

I think he has a unique combination of mild autism, artistic stubborness and scandanavian directness. In the end he makes valid points and he sold me on trying git.

It is hard to tell if he's being serious or if he's just making socially retarded attempts at sarcasm.

Either way he's infinitely more charming than Mr. Zuckerburg...

Sorry this doesn't answer your question but you might find this relevant or at least interesting (and just maybe slightly amusing). http://www.youtube.com/watch?v=4XpnKHJAok8