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