{"thread":{"id":"32571","subject":"git interaction between push and auto-gc","startedAt":"2013-01-09T15:56:49Z","lastAt":"2013-01-09T15:56:49Z","messageCount":1,"participants":["Bob Lavey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"206387","messageId":"kck3vv$mg7$1@ger.gmane.org","threadId":"32571","inReplyTo":null,"subject":"git interaction between push and auto-gc","fromName":"Bob Lavey","fromEmail":"bob.lavey@hp.com","sentAt":"2013-01-09T15:56:49Z","receivedAt":"2013-01-09T15:56:49Z","isPatch":false,"sender":{"key":"bob.lavey@hp.com","avatar":null},"body":"Greetings,\n\nWe are seeing some unexpected behavior with git that we'd like to better \nunderstand.  We are running git 1.7.11.1 on the remote repo server \n(CentOS 6.3-x86) and the clients (mostly Windows 7), and we are running \ngitolite 3.04 on the server.\n\nAt times, our repos can get many unreachable loose objects, and if we \ndon't clean them up, we will see instances where a push to the remote \nrepo does not work correctly.  This almost always occurs when we try to \ndelete a remote branch with a \"git push origin :branch\" call, but this \nweek we saw two occurrences where a push failed to create a branch (as \nwell as about a dozen cases where a push failed to delete the branch). \nThis behavior does not occur for every push, however: I'd guess 10% of \npushes fail.\n\nHere is output from a user's machine:\n\nd:\\git\\jedi\\jedifw>git push origin \nconfigMgrTestBuilder:refs/23s/iq/qbar/user.name@hp.com/jit20073\nCounting objects: 59, done.\nDelta compression using up to 16 threads.\nCompressing objects: 100% (29/29), done.\nWriting objects: 100% (30/30), 129.69 KiB, done.\nTotal 30 (delta 24), reused 1 (delta 0)\nAuto packing the repository for optimum performance.\nwarning: There are too many unreachable loose objects; run 'git prune' \nto remove them.\nTo git@git.boi.hp.com:/jedi/jedifw.git\n\n\nAfter a couple of hours, that user was concerned that their branch \nhadn't started processing, so they sent an email to support and the \nre-pushed.  Here are the lines from the gitolite log showing both of \nthose pushes:\n\ngitolite-2013-01-07.log:2013-01-07.15:57:58     23285   update \njedi/jedifw     user.name@hp.com    W \nrefs/23s/iq/qbar/user.name@hp.com/jit20073 \n0000000000000000000000000000000000000000 \n2ab0e6626c7a51799179993ea0fdbb829a1ea852\n\ngitolite-2013-01-07.log:2013-01-07.19:57:16     30374   update \njedi/jedifw     user.name@hp.com    W \nrefs/23s/iq/qbar/user.name@hp.com/jit20073 \n0000000000000000000000000000000000000000 \n2ab0e6626c7a51799179993ea0fdbb829a1ea852\n\n\nThere are no log entries for that branch or that SHA in between those \ntwo lines.  My understanding is that both of those lines show a new \nbranch being created on the remote repo.  I'm not sure what happened to \nthe first push, though: I expected that the branch would have been \ncreated at that time, and subsequent fetches from the remote repo would \nshow the branch.  However, fetches from the remote repo did not show the \nbranch until after the second push.\n\nWe've been running git for about 3 years, and this happened occasionally \nwhen we first started with git, but we always found it was related to a \nhuge number of unreachable loose objects, which triggered an auto-gc on \nthe remote repo.  When we performed manual gc --aggressive and prune \noperations on the remote repo, the problem stopped.  It happened this \nweek because we'd deleted over 4,000 refs/topics branches on \nFriday/Saturday, which left a huge number of unreachable loose objects. \n  Our cleanup script was only pruning objects older than 2.weeks.ago, \nand when I pruned objects older than 2.days.ago the problem again stopped.\n\nIs this expected behavior for the interaction between pushes and auto-gc \non the remote repo?\n\nAlso, I went through the release notes for the latest versions of git, \nand I found this for 1.7.11.6:\n\n* When \"git push\" triggered the automatic gc on the receiving end, a\n    message from \"git prune\" that said it was removing cruft leaked to\n    the standard output, breaking the communication protocol.\n\nCould that be related to what we're seeing?\n\nThanks,\nBob Lavey\n"}]}