Re: [egit-dev] Missing tree/blob <hash> when trying to push

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

FWIW we have seen these sporadically going back to old versions of Gerrit (in the Maven days) using the native git client to push. Re pushing the same hash from the client didn't work but rebasing the commit (which therefore changed the trees) did fix the issue. We were not able to reproduce the problem in a small enough repository that we could share. So it's a server side issue. 

I think we succeeded when pushing to the standby host (which used the same disk storage but with implicitly different server state cache) but I couldn't say for sure if this always worked. I wonder if the GC causes the caches to be cleared and so fixes the problem that way rather than being a repo data problem.  

Alex

Sent from my iPhat 6

> On 15 Oct 2014, at 09:09, Sascha Vogt <sascha.vogt@xxxxxxxxx> wrote:
> 
> Hi Chris,
> 
> 
>> Am 14.10.2014 um 23:35 schrieb Christian Halstrick:
>> the bugfix is in the generic part of objectwalk. That is used during
>> creation of packfiles. In different use cases it may also influence
>> the server side (e.g. during fetch) but in your case of a failing push
>> operation than the fix is only important for the client side.
> That's what I thought. So Gitblit (server) doesn't matter in this case.
> 
>> your repo is closed source, right? Or could you share the client &
>> server side zips? That would speed up debugging.
> Unfortunately yes, and it's also a pretty big one (250k objects, 1GB,
>> 20k commits) so I won't get approval to share it with anybody. I always
> hope, that it happens on one of our small repos, where I probably could
> convince management to share it with you.
> 
> Nevertheless saving the server state along with the client worked. I
> have now a way to reproduce the issue consistently which makes debugging
> (or verifying potential fixes) easier.
> 
>> If you can't share then I'll prepare tomorrow a modified version of
>> jgit with more tracing and ask you execute it.
> That would be really great.
> 
> In the meantime I reproduced the issue with
> - EGit 3.4.1.201406201815-r
> - EGit 3.5.0.201409260305-r
> - EGit 3.5.1.201410131835-r
> - EGit 3.6.0.201410122131 (versions a bit mixed -> latest nightly from
> 15.10.2014 - 10:00 CEST)
> 
> Greetings
> -Sascha-
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/egit-dev