Why does a merge need you to consider the common ancestor?

Question

I'm learning Git, and am finding the tutorial on this site very useful. On that page, concerning merging, it includes:

         +---------- (D) ---------------+
        /             |                  \
(A) -- (B) -- (C) -------------- (E) -- (F)
                      |                  |
                 fix-headers           master
                                         |
                                        HEAD

The merge commit is (F), having parents (D) and (E). Because (B) is the common ancestor between (D) and (E), the files in (F) should contain the changes between (B) and (D), namely the heading fixes, incorporated into the files from (E).

I don't understand why you would worry about the common ancestor B. Why can't you just merge D and E to produce F? D will have been derived from B but might contain differences you want. There might have been a number of commits between B and D, with changes being made and taken out.

Answer 1

This is simply because merging works better if you know the common ancestor. See this answer, it has good explanation why.

Answer 2

Wikipedia has a good introduction on 3-way merge

Answer 3

(I hesitate to ask if this is an April Fool's, I don't want to insult anyone...)

Maybe you're not understanding that this is git doing the merge for you?

Question: Here are D and E, can you tell me what F should look like?

D                                        E
using System;                            using System;
public void main()                       public void main()
{                                        {
     Console.WriteLine("hello world");        Console.WriteLine("Hello world!");
}                                        }

Answer: No, you can't

However, if you know that B looked like this:

B
using System;
public void main()
{
     Console.WriteLine("hello world");
}

It becomes a no brainer, and git can handle this on its own.

Dunno if that answers your question...