Bugzilla – Full Text Bug Listing
| Summary: | EGit push fails with unpack-objects abnormal exit | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Miles Parker <milesparker> | ||||
| Component: | Core | Assignee: | Project Inbox <egit.core-inbox> | ||||
| Status: | RESOLVED INVALID | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ed, henrik.lindberg, thomas, webmaster | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=346923 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Miles Parker
I don't know what the heck is going on here. I returned to a previous workspace I'd setup for testing and that had failed before, tried the push again from that workspace, and it took. Totally confused at this point.. I don't want to push away any responsibilities but I don't see how Buckminster could influence egit/jgit. We don't register any listeners or such so I can't see how we could interfere in any way. We just call on the git functionality when we need to. That's during resolve and during qualifier resolution. You're the last team I would ever accuse of pushing away responsibilities, if anything you take things on far outside of your area. I'm just not coming up with any ideas that could implicate EGit either, see: http://www.eclipse.org/forums/index.php/mv/msg/209444/671406/#msg_671406 As I note there, this is happening between the time I manually load my releng project and the time I import my Platform project, so there shouldn't even be a git request. OTOH, what happens when you do request something from git? Is there any kind of configuration of the remote happening there? If you can recreate the problem consistently, and it consistently work when you return to the workspace, then maybe there is some information that not gets written/flushed when Buckminster provisions these projects. A restart of eclipse or a change or workspace may cause these to be correctly flushed.... Just a thought. (In reply to comment #4) > If you can recreate the problem consistently, and it consistently work when you > return to the workspace, then maybe there is some information that not gets > written/flushed when Buckminster provisions these projects. A restart of > eclipse or a change or workspace may cause these to be correctly flushed.... It happened again the next time I tried..and changing workspace isn't fixing it. :( I don't remember doing anything with Buckminster since the last successful push. OK, here's a clue. I noticed that my Remote Tracking branch had mysteriously changed from origin/master to origin/origin. Setting it back, I was able to push successfully. But that didn't work exactly the second time. Some magical combination of restarts, checking out again, reediting my changes and then submitting worked. I'm going to uninstall buckminster so we can tell if there is any involvement there. (In reply to comment #6) > OK, here's a clue. I noticed that my Remote Tracking branch had mysteriously > changed from origin/master to origin/origin. When does this happen? Is it when you provision your workspace with Bucky? (In reply to comment #7) > (In reply to comment #6) > > OK, here's a clue. I noticed that my Remote Tracking branch had mysteriously > > changed from origin/master to origin/origin. > > When does this happen? Is it when you provision your workspace with Bucky? Unfortunately, I can confirm that this does seem to be bucky related. I've gone through a couple of cycles of uninstalling buckminster and then reinstalling it. The failures always happen when Buckminster is installed. They seem to happen spontaneously without any explicit triggering, e.g. importing or resolving. Then I have to do a hard reset to be able to commit, obviously the last thing I want to do. Correction. The whole thing is fubar'd now. I don't know why. Sorry to spam, but another update. This does not seem to implicate Buckminster at all. I created a completely new workspace, imported manually without using Buckminster and the same thing happened. I'm going to push over to Egit and see if they have any ideas. To recap, what I'm seeing is: An internal Exception occurred during push: ssh://mparker@git.eclipse.org/gitroot/amp/org.eclipse.amp.git: error occurred during unpacking on the remote end: unpack-objects abnormal exit This is after I successfully pushed a test file to my repos, then edited all the files (for the fourth time now). Is it possible that the repos is simply corrupted? OK, so now I've isolated it to this: I've cloned a fresh repos. I've updated about half of the files by manually copying in the changes from the existing projects on a file by file basis. I did a number of test pushes with changes to a single file. For the first set of changes, I was able to push, see: http://git.eclipse.org/c/amp/org.eclipse.amp.git/commit/?id=d36ce63f0cb1f4d1f97c015782e3ec5ed3a74785 Then I made changes to another set of files. Same error. Corruption is the only explanation I can think of unless there is an evil genie burried somewhere that kills pushes at the worst possible time. At this point I'm reduced to cloning the repository, manually copying a small subset of the files and using divide and conquer to try to discover the problem files. It doesn't appear to be file related either. It literally seems to be random / perverse. Every time I think I've discovered a pattern of failure I'm not able to reproduce it. I was just able to commit and then push 3-4 changes and on the third try I got a failure. Each time this happens, I need to delete the repos entirely and clone a fresh copy. Even a hard reset or fresh checkout doesn't work. Created attachment 196378 [details] Modifying this file may allow the issue to be replicated. OK, I may have been able to restrict it down to a single file, but then again this could just be another false positive. But it rules out corruption in a specific location on my repos. I can reproduce this by doing the following on my local machine: 1. Creating a generic project, sharing it and pushing it to my Eclipse hosted git site. 2. Adding the attached file, committing, pushing. 3. Editing the file, committing, pushing. At that point I got the error again. Note that I am using OS X. Note also that the feature has funky escape characters. One thing I noticed was that in one of the problematic cases the file ended with an LF. My workspace was default encoded for Mac Roman (I don't know why this is still the default), and was using the default line delimiter. A few other interesting errors that only appeared one or twice but may offer clues: org.eclipse.jgit.api.errors.JGitInternalException: No changes at org.eclipse.jgit.api.CommitCommand.createTemporaryIndex(CommitCommand.java:406) at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:192) at org.eclipse.egit.core.op.CommitOperation.commit(CommitOperation.java:243) at org.eclipse.egit.core.op.CommitOperation.access$6(CommitOperation.java:222) at org.eclipse.egit.core.op.CommitOperation$1.run(CommitOperation.java:186) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2326) at org.eclipse.egit.core.op.CommitOperation.execute(CommitOperation.java:196) at org.eclipse.egit.ui.internal.commit.CommitUI$2.run(CommitUI.java:252) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) An internal Exception occurred during push: ssh://mparker@git.eclipse.org/gitroot/amp/org.eclipse.amp.git: Missing tree 7f4ee79d917f775215c55e3712e4775d7cf16edb I'd appreciate it if someone could take a quick look at this to see if you can repeat it. When it fails, command-line fails as well, so I'm asking webmaster to take a look. See related bug. Resolving as invalid because it was neither a Buckminster or EGit issue. See bug 346923. Sorry for the thrashing around on this, but I really couldn't think of any other explanation. I couldn't replicate any cases because there was effectively no pattern to the issue. It would be nice to try to think about better diagnostics for this stuff. I'm not clear why this was resolved. It was and is a real problem. I'm getting it too (on RC4) MDT/OCL has just moved to gitroot/mdt/org.eclipse.ocl.git and we're still setting up. I had a local repository working and had pushed a couple of branches upstream successfully entering a password each time. I then installed my .ssh credentials using Windows->Preferences->General->Network Connections->SSH2->Key Management I did some fetches successfully only needing enter the pass phrase once. I did a trivial change to the active branch involving adding a single file to a new .gitignore. This added and committed to my local repository ok. Pushing upstream repeatedly gives me: Can't connect to any repository: ssh://ewillink@git.eclipse.org/gitroot/mdt/org.eclipse.ocl.git (An internal Exception occurred during push: ssh://ewillink@git.eclipse.org/gitroot/mdt/org.eclipse.ocl.git: error occurred during unpacking on the remote end: unpack-objects abnormal exit) (In reply to comment #16) > I'm not clear why this was resolve0d. It was and is a real problem. > > I'm getting it too (on RC4) > I did a trivial change to the active branch involving adding a single file to a > new .gitignore. This added and committed to my local repository ok. Pushing > upstream repeatedly gives me: > > Can't connect to any repository: > ssh://ewillink@git.eclipse.org/gitroot/mdt/org.eclipse.ocl.git (An internal > Exception occurred during push: > ssh://ewillink@git.eclipse.org/gitroot/mdt/org.eclipse.ocl.git: error occurred > during unpacking on the remote end: unpack-objects abnormal exit) OK, that does sound like just like what happened to me. It's a git issue, but I'm not sure that it's an Egit issue. I'd suggest checking in with Eclipse webmasters and see if there is a similar issue to mine. This sounds like bug 320452. I've fixed the objects/ permissions and added the sharedrepo config option to MDTs repo. -M. Just a note that my issue was also fixed -- under bug 346923 mentioned above. Cured(In reply to comment #18) > This sounds like bug 320452. I've fixed the objects/ permissions and added the > sharedrepo config option to MDTs repo. > > -M. Yes that fixes it. Since the MDT repository was created 6 months after that bug, perhaps you should review your GIT repo creation scripts. |