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,

just to let everybody now: I was able to reproduce our issue on a dummy
repository. I sent the client and server side state to Chris for further
investigation.

If anyone else is interested, ping me and I'll sent it along to you as well.

I even have a prepared Gitblit server ready to go. Just unzip and run it
locally to reproduce the issue.

Still I'm not sure wether this is actually to blame on Gitblit or EGit,
but still, a push from C-Git works and EGit does not.

Greetings
-Sascha-

Am 20.10.2014 um 11:43 schrieb Andrew Eidsness:
> Just to followup on this.  My colleague has reinstalled his IDE and got version 3.4.1 of EGit this time (previously he
> had 3.5.1).  So far he hasn't seen problems.  I'm still running 3.5.1 without issue.
> 
> If his new installation continues to work properly then I think the original issue would be related to a problem in that
> installation (which would also be a better explanation for the UnhandledLoopException problems).
> 
> If he does have problems with this installation he'll try the aggressive gc (which was described in the original thread)
> and I'll report back.
> 
> -Andrew
> 
> On 14-10-17 07:48 AM, Christian Halstrick wrote:
>> I wanted to know which git server you are using: gerrit, gitblit, "git
>> daemon" ... I learned you use gerrit. The git
>> version "1.7.9.5" is I think not relevant. Gerrit is pure java and
>> doesn't use native git (unless you have configured
>> something special). But since you are using gerrit this gives some hints:
>>
>> During push client and server communicate about what should be pushed.
>> The server tells the client which refs
>> he knows and on what IDs they point so the client can produce a
>> packfile which doesn't contain objects which the
>> server already knows. But: if the server is gerrit he does additional
>> checks. E.g. the server said he knows X. The client
>> wants to send Y and Y refers to X. They find out that the only object
>> which has to be sent to the server is Y (not X).
>> But what if X is something which the current user is not allowed to
>> see (by gerrit access rights). Maybe Y points to an
>> object X and X is only availabe on branch "topSecret". The user who
>> pushes is not allowed to read objects from
>> the "topSecret" branch. Means: gerrit checks that all objects which
>> are referred by the objects beeing transported
>> are also accessible by the user.
>>
>> Long story short: It does play a role which user pushes. Maybe you can
>> push because your access rights on gerrit
>> allow you to see X. But maybe your colleague is  not allowed to push
>> because he is referring to objects he's not
>> allowed to see. And for your colleague this may lead to exactly such
>> an "missing object ... " exception.
>>
>> So if it's not too complicated would it possible to let the user try
>> that from your machine to rule out Platform dependency.
>> He should clone on your machine into a new repo amend one commit and
>> push with his credentials. Hopefully
>> that fails also.
>>
>> Ciao
>>   Chris
>>
>>
>> On Fri, Oct 17, 2014 at 1:17 PM, Andrew Eidsness <eclipse@xxxxxxxxxx> wrote:
>>> Thanks for the quick reply!
>>>
>>> I'm not sure what you mean by "kind of git server".  Here is a list of things that it could mean, but let me know if you
>>> mean something different.  Starting from the bottom, it is a Xeon running Ubuntu 12.04.  It has git version 1.7.9.5 and
>>> Gerrit version 2.8.6.1.  We use Gerrit as the interface to git, all pulls are from a Gerrit-based URL and all pushes are
>>> to changesets created in Gerrit.  We're both using the same version of Eclipse and we specifically checked our EGit and
>>> JGit versions to confirm they were identical.
>>>
>>> His use case isn't very involved, and I've tried the same steps on my machine.  It is something that I do frequently
>>> without problems.  His steps are really just "amend a changeset and try to push again".
>>>
>>> One other thing that I forgot to add to the initial description.  He sees alot of "Unhandled loop" exceptions.  Is there
>>> any way this could be related?  I could get the stack trace from him if needed.
>>>
>>> -Andrew
>>>
>>> On 14-10-17 07:06 AM, Christian Halstrick wrote:
>>>> There have been a lot of mails regarding this. But since we are
>>>> talking about traces and debug output from Sascha's closed source
>>>> repository we couldn't talk about that on the public mailing list. But
>>>> any input from other people facing the same problem is of course very
>>>> helpful.
>>>>
>>>> Some questions around your case:
>>>> - which kind of git server are you using
>>>> - is it somehow possible that the user who always sees this problem
>>>> can try his use case from your machine
>>>>
>>>> Ciao
>>>>   Chris



Back to the top