>> On 9 Mar 2012, Timothy Pearson told this:
>>> UPDATE: GIT is actually smart enough it seems, but it is taking many
>>> hours
>>> for it to merge everything correctly.
>>
>> This makes no sense, I'm afraid. git merging is done on the client side,
>> always, and at pull time, never at push time (really at 'git merge'
>> time, which is the second of two steps carried out by 'git pull').
>>
>> Pushing never does a merge of any kind. You can only push on top of a
>> remote branch containing content you haven't pulled if you do a push -f,
>> and that *deletes* the content you haven't pulled (hence the need for a
>> -f 'force' argument).
>>
>> --
>> NULL && (void)
>
> Not quite.  I recognized some problems in GIT that could cause issues, so
> I wrote "babysitting" software that constantly combs through the GIT tree,
> making sure that all submodule references are up to date with the latest
> code and similar housekeeping tasks.  That babysitting software can and
> does trigger commits to the tree, and it is these fixup commits that are
> taking a long time to carry out.
>
> Whatever Darrell did would have effectively wiped out my changes if it
> weren't for the babysitting code. :-)
>
> Tim

Oh, and I forgot to mention: you can in fact push to a tree that contains
content that you have not pulled, and do it without deleting anything. :-)
 I and others have done it many times, and you can see the results here:
http://git.trinitydesktop.org/cgit/tde-packaging/log/

Each one of those "Merge branch 'master' of
http://scm.trinitydesktop.org/scm/git/tde-packaging" was initiated and
computed on the server, not on the client, as a direct result of pushing
to a tree that was newer on the server than it was on the client.  This is
actually one of GIT's strengths; the fact that multiple developers can
work on their own local branches, and then GIT can merge them all together
in a project's master repository at a later date.

Tim