>>> 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

Ah, nevermind, it looks like those merges are done transparently on the
client side.  Sorry for the noise; GIT is a very complex system that I do
not have a complete grasp of (and I suspect most people don't either). :-)

So that leaves the main server resources being utilized for:
1.) Submodule babysitting, due to GIT not having a "real" remote submodule
feature like SVN does
2.) Patchset generation

Both of those are CPU and disk intensive operations.

Tim