Community
Participate
Working Groups
JGit 1.3.0.201201241920 produces this error: org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of commit command at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:277) at org.eclipse.egit.core.op.CommitOperation.commit(CommitOperation.java:255) at org.eclipse.egit.core.op.CommitOperation.access$7(CommitOperation.java:233) at org.eclipse.egit.core.op.CommitOperation$1.run(CommitOperation.java:197) 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:207) at org.eclipse.egit.ui.internal.commit.CommitUI$2.run(CommitUI.java:220) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.io.EOFException: Input did not match supplied length. 829 bytes are missing. at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.shortInput(ObjectDirectoryInserter.java:237) at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.toTemp(ObjectDirectoryInserter.java:168) at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.insert(ObjectDirectoryInserter.java:105) at org.eclipse.jgit.api.CommitCommand.createTemporaryIndex(CommitCommand.java:366) at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:195) ... 8 more $ git config -l core.symlinks=false core.autocrlf=true color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true user.email=stepper@esc-net.de user.name=Eike Stepper core.editor="C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\Uedit32.exe" core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=ssh://estepper@git.eclipse.org/gitroot/cdo/cdo.git branch.master.remote=origin branch.master.merge=refs/heads/master
Workaround: http://egit.eclipse.org/r/#/c/4998/
Hi, when can I expect the workaround appears in nightly-builds. The fact I cannot commit some files is really frustrating. thanks a lot.
I have experienced this issue Mac OS X 10.6.8 SpringSource Tool Suite 2.8.1 RELEASE EGit 1.3.0.201202151440-r It happened for me after renaming a project and carefully updating all affected files (several hundred files changed). After this large change, many packages in my project indicated not being tracked. They were decorated with the '?'. The error condition happened when attempting to commit or add from the project root folder. The problem seems to be related to large amounts of data as Robin Rosenberg suggested. I found two simple work-arounds that got me back into production: 1. Using EGit - Add files a few at a time. I was able to commit all changes in a single pass after adding in small chunks. 2. Using Git - After tiring of many small 'Add to Index' cycles I opened the project root folder in a terminal and executed [code]git add .[/code] Problem solved.
Having the same issue here: Windows XP 32Bit Eclipse Core: 3.8.0.v20110920-2042 Egit: 1.3.0.201202151440-r I don't know if this is of any help, but I use GIT Bash in parallel on the same workspace.
https://git.eclipse.org/r/#/c/4998/ has been merged. Try the next nighly build.
It still happens with JGit 2.0.0.201203181018 ;-(
(In reply to comment #6) > It still happens with JGit 2.0.0.201203181018 ;-( Apparently the patch was was not just ugly, it broke something. -- robin
core.autocrlf=false avoids the bug for me. (messing with line endings is a bad idea anyway)
(In reply to comment #8) > core.autocrlf=false avoids the bug for me. Thanks for the hint. But then I would probably end up with 6000 dirty files due to wrong line endings, again. > (messing with line endings is a bad idea anyway) I consider it a mess if I clone a repo and all files are dirty without me changing something. Or am I missing something?
> > core.autocrlf=false avoids the bug for me. > Thanks for the hint. But then I would probably end up with 6000 dirty files due > to wrong line endings, again. I switched it back to false on a "live" clone and nothing happened. Was I lucky? It's easy enough to see for yourself: simply duplicate your whole project and try. > I consider it a mess if I clone a repo and all files are dirty without me > changing something. "crlf = false" should certainly NOT be a problem as long as: 1. you clone from scratch and, 2. you restrict yourself to modern editors which show equal respect to all files whatever is their origin. The whole idea of source control "fixing" line endings is a hack; avoid it for as long as you can.
*** Bug 375114 has been marked as a duplicate of this bug. ***
Fixed in https://git.eclipse.org/r/#/c/5412/
I'm not sure how useful such "verification" feedback is, but.. I've just run into the exception above, on a 1.3.0, and I can confirm that upgrading to a nightly 2.0.0.20120531 did the magic - thanks!
*** Bug 386868 has been marked as a duplicate of this bug. ***
