TED Conversations

Rich Gittings

This conversation is closed. Start a new conversation
or join one »

At about 10:42 Clay talks about "cooperation w/o coordination". My question is: What if those two programmers made contradictory changes?

At about 10:42 Clay talks about "cooperation w/o coordination". My question is: What if those two programmers made contradictory changes? How would Linux handle it?

Related Talks:
Topics: computer programming linux
0
Share:
progress indicator

  • Guilherme Araujo

    • 0
    Oct 9 2012: Linus choose to integrate one of them. The other one, if not satisfied, could work and maintain his own branch of the software with arbitrary changes.

  • Rich Gittings

    • 0
    Sep 26 2012: Good explanation. Thanks!

  • Mike Dikan

    • +4
    Sep 26 2012: Computer Programmer here:

    Using git as an example, when there is a conflict, the two programmers can do one of two things:

    a: Discuss the conflict and come to a resolution together and adopt a single common project.
    b: Agree to disagree and decide to branch off from each other with their separate solutions.

    At first glance, solution b seems problematic, why can't they just agree on a solution? Well, there are often scenarios when you want the program to branch off into two different solutions - maybe both programmers have a vision for where the project should go, and they are both valid visions that are just inherently different programs. One wants to make the solution web-based, the other wants to make the solution into a mobile app. Any programmer can decide to take any other programmer's work as their starting point, or to take any other programmer's changes as 'canonical' for their own purposes. People gravitate towards the developers with the most respect in the community (just like all other social arenas) and if you are going to disagree with Linus Torvalds, you better have a damn good reason.

    In effect, this means that yes, sometimes projects fork off from each other, but this is a natural part of the development process, and is not something to be discouraged. In practice, it means more choices for the users of the software.
    • thumb

      James Zhang 30+

      • 0
      Sep 27 2012: On a sidenote, I really wish they improved the usability of git.

      I'm not that Linux-fluent and so I'm not used to most of the terminal commands but honestly, I feel like there just has to be a much easier way to use Git, whether it be an improved GUI or just improve the way they teach the concepts.

      But I do agree that what Git does, or what Git is trying to do, is something pretty revolutionary in the open world.

      • Mike Dikan

        • +1
        Sep 27 2012: Try github - it really take a lot of the mystery out of it. They have really simplified the concept of pushing and pulling with the idea of pull requests and the github downloadable app. They have a lot of great tutorials on their site as well.
        • thumb

          James Zhang 30+

          • +1
          Sep 27 2012: Oh no I use it myself, and I'm sure it's come a long way, but I just think there's gotta be an easier way to use it. A good design requires no manual or tutorial to use it.

        • James Bowen

          • 0
          Oct 9 2012: To James, above:
          Problems which are inherently complex often require complex solutions, and simplifying the solution further often leaves part of the original problem unsolved.

          That said, in the case of Git, I do believe it could be much simpler, it's just a question of someone with enough drive and vision getting it done.

    • Eddie Dunn

      • +2
      Sep 28 2012: Option b would be extremely problematic in the case of a working legal document or a public budget. Guess that is where the voting would come in! :)

      • Mike Dikan

        • 0
        Sep 28 2012: Yeah, actually that would be ideal - show that a problem has multiple solutions, and then let the voters just pick the one they like best (or hate the least).
Showing all 10 comments