2

I am wondering how maintainers of a large repo (e.g. the Linux kernel) can merge 'important' branches such as next pu maint etc. How can a single person know how to resolve merge conflicts? I assume such important branches can have diverged by many commits from many different people in different parts of the source tree. Merging two such branches must be done by one person, so you cant split up the conflicts to be resolved by the people beingan expert in the area of a given conflict.

svick
  • 236,525
  • 50
  • 385
  • 514
Florian Kaufmann
  • 803
  • 6
  • 13
  • 1
    Possible duplicate of http://stackoverflow.com/questions/4166530/git-how-to-manage-a-hierarchy-of-committers-like-linux-kernel-dev – nes1983 Apr 15 '12 at 08:59

3 Answers3

2

For very large projects, which the Linux kernel would be one of, it takes a huge amount of communication and coordination between the people who are involved.

The answer is NOT "just see what merge conflicts" and/or "what compiler errors" you get. You need to know why some conflict happened (or will happen) beforehand, and if you don't know who else is making changes that affect you, find out and coordinate ahead of time. Source code managers can help tell you what happened, and who did it, but the goal should be avoiding unexpected problems in the first place, not having to clean up after someone who made a change they shouldn't have made in the first place.

The advantage of having someone like Linus involved is that he has an overall view of the kernel that can help avoid problems before they happen. Your question also raises the issue of the difference between being a typist, a programmer and a software engineer.

The definitive work on software projects is still "The Mythical Man-Month" by Frederick Brooks. The same issues he identified in 1975 with large projects (he was the architect for OS/360 ...) still apply today. Buy it. Read it. Memorize it.

Julie in Austin
  • 966
  • 5
  • 21
1

I think that Linus resolves "easy" merge conflicts. If things get difficult, he asks the patch submitter to figure things out with the lieutenant of the sub system involved. There's a question on Stackoverflow on how Linus runs his project.

Community
  • 1
  • 1
nes1983
  • 15,209
  • 4
  • 44
  • 64
-1

If you get merge errors, that means you edited both the same file, which implicitly means you either know about the content of that file, or you did something you should not do anyways.

In case this happens, tell human A to push to a separate branch x, and let human B resolve the conflicts with that new branch x himself. Merge branch x to master.

drahnr
  • 6,782
  • 5
  • 48
  • 75
  • There's nothing =wrong= with merge conflicts. I have them all the time in my own products and I own the company. The key really is understanding what is going on, and that's a high level communication problem. In large and complex products it isn't unusual to have two developers working in and around the same parts of the product at the same time. So long as the work was partitioned in such a way that the developers are working on relatively independent pieces, resolving conflicts can be a fairly quick and mechanical process =and= neither developer is sitting on their hands the whole time. – Julie in Austin Apr 30 '12 at 06:53
  • What you say is equivalent to the second part of my first sentence. The question was about a way to solve the issue, and I presented one. – drahnr Apr 30 '12 at 07:15
  • No, it isn't. Humans A and B need to COMMUNICATE before the fact. Running off and slinging code like the Lone Ranger is not how software engineering is supposed to be done. There is no "I" in "Team". And while you can spell "Eat Me!" using the letters A, E, M and T, that is not a productive attitude either. – Julie in Austin Apr 30 '12 at 23:10
  • I took communication as granted, as that is what teams usually do anyways - using git or not, merging or not. – drahnr May 01 '12 at 10:18