{"thread":{"id":"18994","subject":"What's going on here? Bad repo, no error locally?","startedAt":"2009-04-22T00:18:22Z","lastAt":"2009-04-22T16:30:55Z","messageCount":7,"participants":["John Dlugosz","Bryan Donlan","John M. Dlugosz","Junio C Hamano","Brandon Casey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111912","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE053E@EXCHANGE.trad.tradestation.com","threadId":"18994","inReplyTo":null,"subject":"What's going on here? Bad repo, no error locally?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-22T00:18:22Z","receivedAt":"2009-04-22T00:18:22Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"Developer B runs git fsck --full, gets no errors but one dangling blob.\nDoes a push. No errors.\nNow, on the upstream repo, I run fsck, and find a bunch of danglings (as\nalways) and a missing blob.\nAny fetch from that repo will fail, due to that missing blob.\n\nWhat's going on? How can I fix his local repository, other than blow it\naway and start over, and copy his current files over and rebuild the few\ncommits of interest?\n\n--John\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"111915","messageId":"3e8340490904212121q4bf2e25dsf5673bff764895c9@mail.gmail.com","threadId":"18994","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE053E@EXCHANGE.trad.tradestation.com","subject":"Re: What's going on here? Bad repo, no error locally?","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-04-22T04:21:20Z","receivedAt":"2009-04-22T04:21:20Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Tue, Apr 21, 2009 at 8:18 PM, John Dlugosz wrote:\n> Developer B runs git fsck --full, gets no errors but one dangling blob.\n> Does a push.  No errors.\n> Now, on the upstream repo, I run fsck, and find a bunch of danglings (as\n> always) and a missing blob.\n> Any fetch from that repo will fail, due to that missing blob.\n>\n> What's going on?  How can I fix his local repository, other than blow it\n> away and start over, and copy his current files over and rebuild the few\n> commits of interest?\n\nExtract the object on developer B's workstation:\ngit cat-file blob > blob.dat\n\nCopy it to upstream, then do:\ngit hash-object -w blob.dat\n\nIf all goes well, hash-object will give you back the blob's ID, and\nthe repository will fsck cleanly again.\n"},{"id":"111916","messageId":"gsm6tr$or7$1@ger.gmane.org","threadId":"18994","inReplyTo":"3e8340490904212121q4bf2e25dsf5673bff764895c9@mail.gmail.com","subject":"Re: What's going on here? Bad repo, no error locally?","fromName":"John M. Dlugosz","fromEmail":"ngnr63q02@sneakemail.com","sentAt":"2009-04-22T04:37:05Z","receivedAt":"2009-04-22T04:37:05Z","isPatch":false,"sender":{"key":"ngnr63q02@sneakemail.com","avatar":null},"body":"Bryan Donlan wrote:\n> Extract the object on developer B's workstation:\n> git cat-file blob > blob.dat\n> \n> Copy it to upstream, then do:\n> git hash-object -w blob.dat\n> \n> If all goes well, hash-object will give you back the blob's ID, and\n> the repository will fsck cleanly again.\n\nThanks, I was looking through the manual for that but wasn't sure how to put it together.\n\nBut, what could be wrong with B's repo that makes this happen repetetly? I assumed it was \nnetwork SNAFU, but after restoring the upstream repo, his push did it again.\n\n--John\n"},{"id":"111918","messageId":"3e8340490904212152w4e308cf1wa0d20d05df3cbb48@mail.gmail.com","threadId":"18994","inReplyTo":"gsm6tr$or7$1@ger.gmane.org","subject":"Re: What's going on here? Bad repo, no error locally?","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-04-22T04:52:29Z","receivedAt":"2009-04-22T04:52:29Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Wed, Apr 22, 2009 at 12:37 AM, John M. Dlugosz\n wrote:\n> Bryan Donlan wrote:\n>>\n>> Extract the object on developer B's workstation:\n>> git cat-file blob  > blob.dat\n>>\n>> Copy it to upstream, then do:\n>> git hash-object -w blob.dat\n>>\n>> If all goes well, hash-object will give you back the blob's ID, and\n>> the repository will fsck cleanly again.\n>\n> Thanks, I was looking through the manual for that but wasn't sure how to put\n> it together.\n>\n> But, what could be wrong with B's repo that makes this happen repetetly?  I\n> assumed it was network SNAFU, but after restoring the upstream repo, his\n> push did it again.\n\nTheoretically, this should never happen :)\nAre you accessing the repo directly through a file share, or through a\ngit-daemon connection?\nIf the former, could something like a virus scanner be deleting loose\nobjects, perhaps?\n"},{"id":"111921","messageId":"7vws9d46q9.fsf@gitster.siamese.dyndns.org","threadId":"18994","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE053E@EXCHANGE.trad.tradestation.com","subject":"Re: What's going on here? Bad repo, no error locally?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-22T05:06:54Z","receivedAt":"2009-04-22T05:06:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John Dlugosz\" writes:\n\n> Developer B runs git fsck --full, gets no errors but one dangling blob.\n> Does a push. No errors.\n> Now, on the upstream repo, I run fsck, and find a bunch of danglings (as\n> always) and a missing blob.\n> Any fetch from that repo will fail, due to that missing blob.\n>\n> What's going on? How can I fix his local repository, other than...\n\nIt sounds like there is nothing to fix in \"his local repository\"; the\nerror is in your \"upstream repo\".\n\nThe dangling objects can happen if you push over dumb transport and\ninterrupt in the middle, or you force a push of a rewound branch, so it\ndoes not necessarily indicate any errors, but a missing object is always\nan error.\n"},{"id":"111961","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE06C1@EXCHANGE.trad.tradestation.com","threadId":"18994","inReplyTo":"7vws9d46q9.fsf@gitster.siamese.dyndns.org","subject":"RE: What's going on here? Bad repo, no error locally?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-22T15:59:41Z","receivedAt":"2009-04-22T15:59:41Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> The dangling objects can happen if you push over dumb transport and\n> interrupt in the middle, or you force a push of a rewound branch, so\nit\n> does not necessarily indicate any errors, but a missing object is\n> always an error.\n\n\nThanks.\n\nThat's what I thought danglings were. But why doesn't gc get rid of\nthem?\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"111962","messageId":"E0D2gLN_Jf9hLR8B78bVz8eX4lf5i3HBnK3k4LcAakE@cipher.nrlssc.navy.mil","threadId":"18994","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE06C1@EXCHANGE.trad.tradestation.com","subject":"Re: What's going on here? Bad repo, no error locally?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2009-04-22T16:30:55Z","receivedAt":"2009-04-22T16:30:55Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"John Dlugosz wrote:\n>> The dangling objects can happen if you push over dumb transport and\n>> interrupt in the middle, or you force a push of a rewound branch, so\n> it\n>> does not necessarily indicate any errors, but a missing object is\n>> always an error.\n> \n> \n> Thanks.\n> \n> That's what I thought danglings were. But why doesn't gc get rid of\n> them?\n\nJeff already explained why in his email to you about \"dangling commits ...\".\n\nWhat you may not realize (and Jeff hinted at) is that unreferenced objects\nare created often. This is because the object must be created _before_\nthe reference to the object is created. The existence of a reference to an\nobject is what differentiates a dangling,unreferenced object from one that is\nnot dangling,unreferenced. Usually, an unreferenced object exists in the\nrepository for a very short time before becoming referenced by the creation\nof a commit which references it. But, there is always some period of time\nthat an object exists in the repository as a dangling,unreferenced object.\nThat is why gc does not delete all dangling,unreferenced objects that it\nencounters immediately. As Jeff pointed out, it only deletes those that are\ntwo weeks old by default.\n\n-brandon\n"}]}