What's going on here? Bad repo, no error locally?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

What's going on here? Bad repo, no error locally?

John Dlugosz
Developer B runs git fsck --full, gets no errors but one dangling blob.
Does a push.  No errors.
Now, on the upstream repo, I run fsck, and find a bunch of danglings (as
always) and a missing blob.
Any fetch from that repo will fail, due to that missing blob.

What's going on?  How can I fix his local repository, other than blow it
away and start over, and copy his current files over and rebuild the few
commits of interest?

--John

TradeStation 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. If you received this in error, please contact the sender and delete the material from any computer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: What's going on here? Bad repo, no error locally?

Bryan Donlan
On Tue, Apr 21, 2009 at 8:18 PM, John Dlugosz <[hidden email]> wrote:
> Developer B runs git fsck --full, gets no errors but one dangling blob.
> Does a push.  No errors.
> Now, on the upstream repo, I run fsck, and find a bunch of danglings (as
> always) and a missing blob.
> Any fetch from that repo will fail, due to that missing blob.
>
> What's going on?  How can I fix his local repository, other than blow it
> away and start over, and copy his current files over and rebuild the few
> commits of interest?

Extract the object on developer B's workstation:
git cat-file blob <object ID>  > blob.dat

Copy it to upstream, then do:
git hash-object -w blob.dat

If all goes well, hash-object will give you back the blob's ID, and
the repository will fsck cleanly again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: What's going on here? Bad repo, no error locally?

John M. Dlugosz
Bryan Donlan wrote:
> Extract the object on developer B's workstation:
> git cat-file blob <object ID>  > blob.dat
>
> Copy it to upstream, then do:
> git hash-object -w blob.dat
>
> If all goes well, hash-object will give you back the blob's ID, and
> the repository will fsck cleanly again.

Thanks, I was looking through the manual for that but wasn't sure how to put it together.

But, what could be wrong with B's repo that makes this happen repetetly?  I assumed it was
network SNAFU, but after restoring the upstream repo, his push did it again.

--John

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: What's going on here? Bad repo, no error locally?

Bryan Donlan
On Wed, Apr 22, 2009 at 12:37 AM, John M. Dlugosz
<[hidden email]> wrote:

> Bryan Donlan wrote:
>>
>> Extract the object on developer B's workstation:
>> git cat-file blob <object ID>  > blob.dat
>>
>> Copy it to upstream, then do:
>> git hash-object -w blob.dat
>>
>> If all goes well, hash-object will give you back the blob's ID, and
>> the repository will fsck cleanly again.
>
> Thanks, I was looking through the manual for that but wasn't sure how to put
> it together.
>
> But, what could be wrong with B's repo that makes this happen repetetly?  I
> assumed it was network SNAFU, but after restoring the upstream repo, his
> push did it again.

Theoretically, this should never happen :)
Are you accessing the repo directly through a file share, or through a
git-daemon connection?
If the former, could something like a virus scanner be deleting loose
objects, perhaps?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: What's going on here? Bad repo, no error locally?

Junio C Hamano
In reply to this post by John Dlugosz
"John Dlugosz" <[hidden email]> writes:

> Developer B runs git fsck --full, gets no errors but one dangling blob.
> Does a push.  No errors.
> Now, on the upstream repo, I run fsck, and find a bunch of danglings (as
> always) and a missing blob.
> Any fetch from that repo will fail, due to that missing blob.
>
> What's going on?  How can I fix his local repository, other than...

It sounds like there is nothing to fix in "his local repository"; the
error is in your "upstream repo".

The dangling objects can happen if you push over dumb transport and
interrupt in the middle, or you force a push of a rewound branch, so it
does not necessarily indicate any errors, but a missing object is always
an error.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: What's going on here? Bad repo, no error locally?

John Dlugosz
> The dangling objects can happen if you push over dumb transport and
> interrupt in the middle, or you force a push of a rewound branch, so
it
> does not necessarily indicate any errors, but a missing object is
> always an error.


Thanks.

That's what I thought danglings were.  But why doesn't gc get rid of
them?


TradeStation 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. If you received this in error, please contact the sender and delete the material from any computer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: What's going on here? Bad repo, no error locally?

Brandon Casey
John Dlugosz wrote:

>> The dangling objects can happen if you push over dumb transport and
>> interrupt in the middle, or you force a push of a rewound branch, so
> it
>> does not necessarily indicate any errors, but a missing object is
>> always an error.
>
>
> Thanks.
>
> That's what I thought danglings were.  But why doesn't gc get rid of
> them?

Jeff already explained why in his email to you about "dangling commits ...".

What you may not realize (and Jeff hinted at) is that unreferenced objects
are created often.  This is because the object must be created _before_
the reference to the object is created.  The existence of a reference to an
object is what differentiates a dangling,unreferenced object from one that is
not dangling,unreferenced.  Usually, an unreferenced object exists in the
repository for a very short time before becoming referenced by the creation
of a commit which references it.  But, there is always some period of time
that an object exists in the repository as a dangling,unreferenced object.
That is why gc does not delete all dangling,unreferenced objects that it
encounters immediately.  As Jeff pointed out, it only deletes those that are
two weeks old by default.

-brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html