5 ms·

This can not be posted too many times. https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds talk on Google a

by Puts 5y ago

This can not be posted too many times. https://www.youtube.com/watch?v=4XpnKHJAok8 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 5y ago
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.
- deleted 5y ago
  [deleted]
- nix0n 5y ago
  > 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 5y ago
    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.
    - kubanczyk 5y ago
      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 5y ago
        Explain how you think git is different in this regard.
        detaro 5y ago
        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 5y ago
        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 5y ago
        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.

by Puts 5y ago

jeffbee 5y ago

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.

deleted 5y ago
[deleted]
nix0n 5y ago
> 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 5y ago
  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.
  - kubanczyk 5y ago
    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 5y ago
      Explain how you think git is different in this regard.
      - detaro 5y ago
        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 5y ago
        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 5y ago
      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.