Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Missing tree/blob <hash> when trying to push

Hi,

today it happened again on a colleagues machine (unfortunately again on
a repository which I cannot share).

We ran "git reflog expire --expire=now --all" and "git gc --aggressive
--prune=now" on the repository, unfortunately EGit still complains about
a missing tree object.

Am 10.10.2014 um 09:40 schrieb Christian Halstrick:
>> We also usually manually run a "git gc" which on all but one occasion
>> didn't fix the issue. The next time it arises I'll test if a
>>     git reflog expire --expire=now --all
>>     git gc --aggressive --prune=now
>> helps.
> 
> Right. You have to make sure the reflogs are clean and gc is run aggressive.
> Afterwards a "git fsck" should not show any dangling objects.
Output of git fsck --full:
$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (443044/443044), done.
Checking connectivity: 443044, done.

So no dangling commits.
Nevertheless pushing didn't work.

We also updated EGit to 3.5.1.201410131835-r which should include your
"markUnintersting" patch.

>> Is there anything else I could do / test if it fixes the issue (apart
>> from a C-Git push)?
> 
> Most important would be save the state of client and server when the problem
> occurs. If we have a reproduce able state than this is very valuable.
> The problem
> which I have in mind is still there after a failed push with EGit. But
> any native
> git operation on the client repo afterwards can clean the situation. And if the
> the server refs are updated then this also changes the situation. If you can't
> save the server state the you could also clone the server repo (fetching all
> advertised refs, not only branches/tags)
Saved the repo on both the server and the client. Hopefully that way
it's reproducible :)

> The workflow you describe seems to be pretty normal. But there is something
> special with gerrit in this situation. To produce the bug you have to do a push
> and the server has to advertise refs which are in your local repo unreferenced.
> Because gerrit advertises every single commit pushed to code review underneath
> "refs/changes/xy/z" it is very likely that the server advertises refs which the
> local repo know about but which are now unreferenced. I would guess that
> gerrit servers are more likely to produce the situation that the push fails than
> other git servers. 
Server is Gitblit this time.

Anything else I could / should try?

Greetings
-Sascha-


Back to the top