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