Community
Participate
Working Groups
Out of a sudden the nodes/configuration under "Remotes" disappears from time to time. Today I faced this issue two times for two different repositories. Currently I'm using eGit 3.5.2 in Eclipse 4.4.1, but this issue already occurred with previous versions of eGit in Eclipse Kepler. So far I was not able to identify a specific situation/interaction which causes this problem. I also don't see entries in the Eclipse error log that seems to be related to this problem (IDE started this morning, last eGit related log entry from yesterday). Are there tracing options that can be activated to log more details about what happens in eGit to identify when/why the configuration gets lost? Regards, Felix
This is still an issue in EGit 3.7. This has happened to me on more than one machine (counting 3 now), at random times, multiple times. It is not just a once or twice occurrence and today was the latest occurrence. It's frequency may happen around once a month or so. I have had it happen with the previous version of EGit too. I have checked the error log view and it reported nothing. Is there some way we can increase the importance of this and try to track it down? The main issue I have with this is I have to retrack down what URLs I am using for all the repositories that get affected. Some are shared drive file paths that aren't listed anywhere and some of my repositories have multiple remotes for other co-workers. eclipse.buildId=4.3.2.M20140221-1700 java.version=1.7.0_40 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
Hmm, that's hard to debug. I personally never lost a remote configuration. Which remotes are known to EGit is persisted in the .git/config file. To remove such a remote EGit whould have to delete the complete file or explicitly rewrite this file removing a specific remote. I can't see in the code how this could happen. But maybe I am missreading your bug report: What exactly do you mean with "nodes/configuration"? In which view did you see something which got deleted? In "Repositories View" when expanding "YourRepo"->Remotes ? Maybe a screenshot helps.
Created attachment 252256 [details] lost nodes (screenshot from Git Repositories view) The marked nodes disappeared. There was not a single node below "Remotes".
Felix's screen is the same for me. For me personally, I use the "Git Repositories" view inside the "Java EE" and "Git" perspective. I switch between the 2 perspectives alot. What I had disappear is under "[Repository] > Remotes" in "Git Repositories" view. I usually don't notice it gone until I do a push/pull and it fails with the exception "nothing to fetch". When I notice the exception, I go directly to the "Remotes" under "Git Repositories" and it doesn't expand and shows nothing in it. I re-add the remote and it works like normal again. I did not know the file that was responsible for the remotes. I will try to keep an eye on it and report if I see anything when it happens again.
It would be interesting to see the content of the file $GIT_DIR/config for the repo which has "lost his remotes". If the file exists and if it still contains the remote specifications you don't see anymore in the UI then I would ask you to try to restart eclipse. The information about the remotes is read from that file and a restart should reread that info. Of course it's an not acceptable bug if you have to restart eclipse but I just want to find out first what's broken in the persisted data in the filesystem.
@Christian Halstrick: Can you confirm this for me? In a test, I deleted my ".git\config" file and opened the workspace in Eclipse and like we reported the remotes were gone. I looked in the "Error Log" and I am seeing these errors from EGit. Is the missing config file responsible for these errors and do they always come up? As I said in my first report, I did check the error log when the issue happened yesterday and I saw nothing reported from EGit. In the test with the file gone, I am getting 9 error logs, 8 from EGit. I would like to think I didn't miss these when I looked, but maybe the remotes were gone from another instance of using eclipse and I didn't notice when I closed it out. When I closed eclipse the config file is still gone, not recreated. When I reopened eclipse again I only got the readPipe error, not any of the other 8 errors. org.eclipse.m2e.logback.appender Caught exception in FS.readPipe() An exception stack trace is not available. Remove repository mapping of Git mapped resource for which project or mapped git repository has disappeared: 'RepositoryMapping[<empty> -> '../.git', absolute path: 'D:/Rickys/Java/EnterpriseWorkspaceEclipse/.git' ]' java.io.FileNotFoundException: at org.eclipse.egit.core.project.GitProjectData.logAndUnmapGoneMappedResource(GitProjectData.java:531) at org.eclipse.egit.core.project.GitProjectData.map(GitProjectData.java:497) at org.eclipse.egit.core.project.GitProjectData.remapAll(GitProjectData.java:471) at org.eclipse.egit.core.project.GitProjectData.load(GitProjectData.java:464) at org.eclipse.egit.core.project.GitProjectData.get(GitProjectData.java:204) at org.eclipse.egit.core.GitProvider.getData(GitProvider.java:86) at org.eclipse.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:318) at org.eclipse.egit.ui.Activator$ResourceRefreshJob.triggerRefresh(Activator.java:434) at org.eclipse.egit.ui.Activator$1.windowActivated(Activator.java:287) at org.eclipse.ui.internal.Workbench$11.run(Workbench.java:995)
If the .git/config file is missing then you don't have a git repository anymore (from JGit's perspective). It is created automatically when you clone or when you initialize a new repo and should never be deleted. Therefore it makes sense to see error message like "for which ... mapped git repository has disappeared". It is crucial to find out who deletes that file.
Today I have lost the "Remotes" configuration again. The config file was still there but in was almost empty. The only entry described the currently active local branch. Even the second local branch did not appear in the file. I was not able the reproduce the problem. The most "significant" thing while working with EGit was the deletion of a remote branch. I don't know if this could cause such a behaviour.
What do you mean with "deletion of a remote branch"? - Did you do some actions in EGit to trigger that a remote branch should be deleted (Similar to "git push -f origin :refs/heads/side") - Or was a branch on the remote system beeing deleted by somebody else? - Or did you just deleted a local remote-tracking-branch (equivalent of just locally deleting the file .git/refs/remote/origin/side)
I lost a configuration again: * Remote branch A * local branch local-A (remote A configured as upstream), not checked out * delete remote branch A (using the connected Gerrit UI) * fetch changes from remote in EGit (fetch.prune=true) => loss of Remote configuration config file still exists, the only entry (2 lines) describes the currently checked out branch [branch "<name of branch>"] rebase = true
This problem has been happening to me sporadically for a few years now. I never knew what triggered it but today I saw it happen while I was staring at my Git Repositories view: 1. I created a new local 'master' branch and checked it out. 2. I selected 15-20 old local branches (all created using "Fetch from Gerrit") 3. I right-clicked the selection and clicked "Delete Branch" While the branches were being deleted (it took 1-2 seconds) I actually saw the remote item disappear and the Remotes tree item become childless. It seems that the whole Repository Settings file gets wiped out (<git root>\<repository>\.git\config). If I click Open from the preference page and copy and paste the text in the editor from a backup config file that I have learned to keep over the years ;) then save and press Refresh in Git Repositories, everything comes back to normal. This is running eGit 3.4.2 on Windows.
The same problems happens quite a lot recently. After analyzing the problem I agree with "Patrick Tasse". The problem occurs while deleting a local branches. I have tried to find a simple way to reproduce but I could not find it. I have tries several use cases (that matched the configuration of my repository): * Deletion of more than one local branch in the same time (multi selection) * Having multiple remotes * Having a gerrit configuration set up for this project None of them works. If I find more information I will publish it here but for now it still is a mystery. Running: EGit 4.1.0 Jgit 4.1.0
New Gerrit change created: https://git.eclipse.org/r/45823
you can try to use this patch which adds some logging to identify the root cause https://git.eclipse.org/r/#/c/45823/
I have built a custom version of JGit 4.1.1 with your patchset. I will deploy it on the platform of some people in my team (that have the same problem). What should I do to activate the log? Regards, Arthur
looks like I missed to add a log4j configuration, add something like https://git.eclipse.org/r/#/c/56391/20/org.eclipse.jgit.test/tst-rsrc/log4j.properties to the org.eclipse.jgit bundle You need to set the logger org.eclipse.jgit.storage.file.FileBasedConfig to DEBUG level There is no way yet to tweak the logging configuration at runtime, see bug 476639
I have deployed your patch set on several computer on my team. Let's hope next time the bug occurs, we will have enough information to correct it. Regards, Arthur
It happened again. This this I had your patchset included in my platform. Could you tell me where should I look for the log file (I did not find any at this time). What I can tell is. It happened while deleting 4 local branches just before starting the plaftorm. I believe this might be an important part of the puzzle. I suspect a side effect with EGit while initializing the repository. One more important information is that this time the remotes have disappeared from the view but the config file is still present in my repository (maybe your patcheset corrects a part of the problem).
New Gerrit change created: https://git.eclipse.org/r/60939
Gerrit change https://git.eclipse.org/r/60939 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=d2faec27a7af7c9ea7db6b4ac31f75533ca45b80
I think https://git.eclipse.org/r/#/c/60939/5/org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileBasedConfig.java should fix this problem. As this problem wasn't reproducible but was reported again and again we will mark this bug resolved. If someone again faces this problem using JGit 4.2.0.201511290455 or later then please reopen this bug and provide details.
I gonna install this version on all the platform for my dev team (since we reproduce at least once a month). Is there an official release or should I use http://download.eclipse.org/egit/updates-nightly update site? Regards, Arthur
(In reply to Arthur Daussy from comment #22) > I gonna install this version on all the platform for my dev team (since we > reproduce at least once a month). Is there an official release or should I > use http://download.eclipse.org/egit/updates-nightly update site? http://download.eclipse.org/egit/updates-nightly is an *official* nightly build site and yes, this is the site to use to see the fix :-)
I added the updates-nightly repository and updated EGit to version 4.2.0.201512080831 and restarted Eclipse. I then selected 8 old branches and did "Delete Branch". "Remotes" got lost. I got the following Exception in my error log. That was running on Windows, which fails at deleting files that are in use by another process, unlike Linux. The Eclipse build is M20150904-0015. !ENTRY org.eclipse.jface 4 2 2015-12-09 10:20:49.478 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.RuntimeException: java.io.FileNotFoundException: C:\Users\user\git\org.eclipse.myproject\.git\config (The process cannot access the file because it is being used by another process) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:400) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:111) at org.eclipse.jgit.lib.BranchTrackingStatus.of(BranchTrackingStatus.java:75) at org.eclipse.egit.ui.internal.GitLabels.getStyledLabel(GitLabels.java:127) at org.eclipse.egit.ui.internal.GitLabels.getStyledLabelExtendedSafe(GitLabels.java:192) at org.eclipse.egit.ui.internal.repository.RepositoriesViewLabelProvider.getStyledText(RepositoriesViewLabelProvider.java:346) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateCommonLabelProvider.getStyledText(SafeDelegateCommonLabelProvider.java:118) at org.eclipse.ui.internal.navigator.NavigatorContentServiceLabelProvider.findStyledText(NavigatorContentServiceLabelProvider.java:167) at org.eclipse.ui.internal.navigator.NavigatorContentServiceLabelProvider.getStyledText(NavigatorContentServiceLabelProvider.java:153) at org.eclipse.ui.internal.navigator.NavigatorDecoratingLabelProvider$StyledLabelProviderAdapter.getStyledText(NavigatorDecoratingLabelProvider.java:63) at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.getStyledText(DelegatingStyledCellLabelProvider.java:206) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.getStyledText(DecoratingStyledCellLabelProvider.java:199) at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.update(DelegatingStyledCellLabelProvider.java:106) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.update(DecoratingStyledCellLabelProvider.java:136) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:154) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:949) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:114) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1029) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:473) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2176) at org.eclipse.jface.viewers.StructuredViewer.internalUpdate(StructuredViewer.java:2159) at org.eclipse.jface.viewers.StructuredViewer.update(StructuredViewer.java:2097) at org.eclipse.jface.viewers.ColumnViewer.update(ColumnViewer.java:541) at org.eclipse.ui.navigator.CommonViewer.update(CommonViewer.java:510) at org.eclipse.jface.viewers.StructuredViewer.update(StructuredViewer.java:2041) at org.eclipse.jface.viewers.StructuredViewer.handleLabelProviderChanged(StructuredViewer.java:1208) at org.eclipse.ui.navigator.CommonViewer.handleLabelProviderChanged(CommonViewer.java:236) at org.eclipse.jface.viewers.ContentViewer$1.labelProviderChanged(ContentViewer.java:99) at org.eclipse.jface.viewers.BaseLabelProvider$1.run(BaseLabelProvider.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173) at org.eclipse.jface.viewers.BaseLabelProvider.fireLabelProviderChanged(BaseLabelProvider.java:69) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider$1.labelProviderChanged(DecoratingStyledCellLabelProvider.java:78) at org.eclipse.ui.internal.decorators.DecoratorManager$1.run(DecoratorManager.java:446) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.DecoratorManager.fireListener(DecoratorManager.java:443) at org.eclipse.ui.internal.decorators.DecorationScheduler$3.runInUIThread(DecorationScheduler.java:536) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:97) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4155) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3772) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:172) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:387) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:500) at org.eclipse.egit.ui.internal.repository.tree.command.DeleteBranchCommand.execute(DeleteBranchCommand.java:73) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:799) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:675) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:659) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:592) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4180) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3769) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608) at org.eclipse.equinox.launcher.Main.run(Main.java:1515) Caused by: java.io.FileNotFoundException: C:\Users\user\git\org.eclipse.myproject\.git\config (The process cannot access the file because it is being used by another process) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(Unknown Source) at java.io.FileInputStream.<init>(Unknown Source) at org.eclipse.jgit.util.IO.readFully(IO.java:141) at org.eclipse.jgit.util.IO.readFully(IO.java:81) at org.eclipse.jgit.storage.file.FileBasedConfig.load(FileBasedConfig.java:144) at org.eclipse.jgit.internal.storage.file.FileRepository.loadRepoConfig(FileRepository.java:251) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:398) ... 96 more
I should note that previously when I lost the "Remotes", the 'config' file was then empty (or deleted, I'm not sure). But this time, I can see the original config in Window > Preferences > Team > Git > Configuration > Repository Settings > Open. Clicking "Refresh" button with the repository selected in "Git Repositories" view has no effect and doesn't bring the "Remotes" back. However, after making a dummy change in the opened "config" text editor and saving the file, then clicking "Refresh" does bring the "Remotes" back.
Something is not clear to me. If you now "lost the remotes" and inspect the filesystem with Explorer: do you still see the $GIT/config file or not?
(In reply to Christian Halstrick from comment #26) Because I was able to see the raw contents in an editor by clicking "Open" in the Git repository preferences, I'm assuming the file was intact in the file system, but I didn't verify that. It seems like the git config had been removed from the EGit UI model which couldn't be refreshed even though the file contents were intact. It could only refresh successfully after making a modification to the config. I did it through the text editor, next time I see it, I will try to modify directly the config from the table in the preference page, and I'll check the file system at the same time.
It happened again. One again I have started my platform and I deleted 8 local branches. I lost all the remote configuration. The .git/config file was not deleted but it was empty. By the way: Best wishes for this new year. Installation: Eclipse Git Team Provider 4.2.0.201512080831 org.eclipse.egit.feature.group Eclipse EGit Java implementation of Git 4.2.0.201512080738 org.eclipse.jgit.feature.group Eclipse JGit
I have the same problem, very frequently too. Since I have a lot of local branches due to the use of gerrit, I often have to delete say 10 branches at once; quite ofen, I'm losing my config then. I've got accustomed to opening the file before the delete, then when eclipse asks me about replacing the contents with the new one (=empty), saying no and saving again. Is there anything I can do to help debugging the problem further?
(In reply to Missing name from comment #29) > I have the same problem, very frequently too. Since I have a lot of local > branches due to the use of gerrit, I often have to delete say 10 branches at > once; quite ofen, I'm losing my config then. I've got accustomed to opening > the file before the delete, then when eclipse asks me about replacing the > contents with the new one (=empty), saying no and saving again. > > Is there anything I can do to help debugging the problem further? Which EGit version are you using ? We did some fixes in 4.2 so try with this version if you don't use it yet. It's available in Eclipse marketplace or from http://download.eclipse.org/egit/updates
I still just got the problem after deleting about 12 branches; the .git\config file was empty afterwards. I'm using Eclipse Git Team Provider 4.2.0.201601211800-r under Eclipse Mars.2 on Windows 7. At about the same time I saw the following entry twice in the Eclipse Error logs: An internal error occurred during: "Reloading Quick Diff information". java.lang.RuntimeException: java.io.FileNotFoundException: C:\Workspaces\Eclipse45-Mars\git-repos\myrepo\.git\config (The process cannot access the file because it is being used by another process) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:413) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:112) at org.eclipse.egit.ui.internal.decorators.GitDocument.populate(GitDocument.java:161) at org.eclipse.egit.ui.internal.decorators.GitDocument$1.run(GitDocument.java:273) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.io.FileNotFoundException: C:\Workspaces\Eclipse45-Mars\git-repos\myrepo\.git\config (The process cannot access the file because it is being used by another process) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(Unknown Source) at java.io.FileInputStream.<init>(Unknown Source) at org.eclipse.jgit.util.IO.readFully(IO.java:141) at org.eclipse.jgit.util.IO.readFully(IO.java:81) at org.eclipse.jgit.storage.file.FileBasedConfig.load(FileBasedConfig.java:144) at org.eclipse.jgit.internal.storage.file.FileRepository.loadRepoConfig(FileRepository.java:264) at org.eclipse.jgit.internal.storage.file.FileRepository.getConfig(FileRepository.java:411) ... 4 more eclipse.buildId=4.5.2.M20160212-1500 java.version=1.8.0_74 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product -product org.eclipse.epp.package.jee.product
New Gerrit change created: https://git.eclipse.org/r/120130
Had this happen to me as well. Am on Windows 10. I can see that the /.git/config file is not deleted, but it's content is wiped, as the creation date of the file on the file system is from way before the issue occured. The only error in the log between when I still had the content and after it disappeared is the one below, but I doubt it is related, because I've had such an error on other occasions and then the remotes didn't get wiped: !ENTRY org.eclipse.core.jobs 4 2 2018-03-28 09:03:40.142 !MESSAGE An internal error occurred during: "Discard Changes". !STACK 0 org.eclipse.jgit.api.errors.JGitInternalException: Checkout conflict with file: xxxx/yyyy.js at org.eclipse.jgit.api.CheckoutCommand.checkoutPath(CheckoutCommand.java:462) at org.eclipse.jgit.api.CheckoutCommand.access$200(CheckoutCommand.java:126) at org.eclipse.jgit.api.CheckoutCommand$2.apply(CheckoutCommand.java:451) at org.eclipse.jgit.dircache.DirCacheEditor.applyEdits(DirCacheEditor.java:160) at org.eclipse.jgit.dircache.DirCacheEditor.finish(DirCacheEditor.java:122) at org.eclipse.jgit.dircache.BaseDirCacheEditor.commit(BaseDirCacheEditor.java:197) at org.eclipse.jgit.dircache.DirCacheEditor.commit(DirCacheEditor.java:117) at org.eclipse.jgit.api.CheckoutCommand.checkoutPathsFromCommit(CheckoutCommand.java:455) at org.eclipse.jgit.api.CheckoutCommand.checkoutPaths(CheckoutCommand.java:393) at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:204) at org.eclipse.egit.core.op.DiscardChangesOperation.discardChanges(DiscardChangesOperation.java:206) at org.eclipse.egit.core.op.DiscardChangesOperation.discardChanges(DiscardChangesOperation.java:166) at org.eclipse.egit.core.op.DiscardChangesOperation.access$0(DiscardChangesOperation.java:155) at org.eclipse.egit.core.op.DiscardChangesOperation$1.run(DiscardChangesOperation.java:148) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241) at org.eclipse.egit.core.op.DiscardChangesOperation.execute(DiscardChangesOperation.java:151) at org.eclipse.egit.ui.internal.actions.DiscardChangesActionHandler$1.runInWorkspace(DiscardChangesActionHandler.java:57) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.io.IOException: Could not rename file C:\workspaces\aaaa\bbbb\cccc\xxxx\._yyyy.js8967976733008278971.tmp to C:\workspaces\aaaa\bbbb\cccc\xxxx\yyyy.js at org.eclipse.jgit.dircache.DirCacheCheckout.checkoutEntry(DirCacheCheckout.java:1188) at org.eclipse.jgit.api.CheckoutCommand.checkoutPath(CheckoutCommand.java:460) ... 18 more Some other relevant this (possibly): - in My User settings I've got fetch.prune=true - I had local branches with remotes that got deleted overnight (by a dev in another timezone) after a merge into master - I'm on Eclipse 4.5.0.v20150603-2358 and Eclipse Git Team Provider 4.1.1.201511131810-r
Just realized I was on quite an older version of the git plugin (since I'm bound to an older version of Eclipse for now, I wasn't getting notifications for the newer versions). Just updated, will report back if it happens again
EGit 5.1.3 Lost "Remotes" config file becomes: [branch "master"] merge = refs/heads/master remote = . rebase = false
seen it today: selected and deleted 2 local branches (that is, multiple deletion in one gesture) - fwiw: one of the deleted was the checkout of a remote - the other had no direct equivalent branch on the remote after doing so, the Remotes tree item had no children, the config file was empty pretty sure (but slightly less than 100% because I did not pay any attention at that time ;) that before the deletion the Remotes item had the child triangle, that is still knew its remotes Versions: Eclipse details: from about dialog Version: 2020-12 (4.18.0) Build id: 20201210-1552 Egit Eclipse EGit Git integration for Eclipse 5.13.0.202109080827-r org.eclipse.egit
I had looked at this in the past, but not found anything conclusive. But now I think I see what's happening. This problem is specific to Windows, which may have problems with atomic file moves, and it has multiple causes. 1. JGit uses a LockFile when writing a config file (correctly so), but not when reading. I've never been happy about this, but it's been like this since before JGit was moved to Eclipse (to be precise, since July 26, 2009) and I don't know why. So reads and writes for config files can occur concurrently. 2. The problem does not occur on systems where atomic file moves are always atomic, and always work. Unfortunately Windows is not such a system. 3. LockFile.commit(), which is used to update a FileBasedConfig, has a fall-back path if the atomic file move doesn't work in which it deletes the file and then performs the move again. 4. FileBasedConfig.load(), which doesn't use a LockFile, re-tries a few times. But it stops if it gets a FileNotFoundException, and the file really doesn't exist on disk. In that case it returns an empty config. Obviously, if reads can occur concurrently with writes, the file may be missing temporarily because of (3). 5. When that happens, FileBasedConfig still uses a FileSnapshot obtained earlier, at which time the file might still have existed. So the FileSnapshot and the in-memory config content will not agree, which may cause trouble later. 6. JGit's DeleteBranchCommand updates the config for each branch it deletes. This fires a "config changed" event, which will cause other parts of EGit to refresh (for instance, the history view, or the repositories view itself). These refreshes will access the git config, and may/will read it from disk. The refreshes will occur in a different thread. Meanwhile, JGit will continue with deleting the next branch: so we have a clear potential of config reads and writes occurring concurrently, which increases the likelihood 1-5 happening. 7. On top of that, EGit's DeleteBranchOperation calls JGit's DeleteBranchCommand for each branch individually. I'm not sure how this could be fixed for good, except also using LockFile for reading. But I do strongly suspect that there was a good reason not to do so... Otherwise, I see only ways to attempt to make it far less likely that this problem occurs: a. Update the FileSnapohot obtained in FileBasedConfig.load() only if the file could indeed be read. b. Perhaps use in-process synchronization between reading and writing configs? That would at least avoid the problem if caused by different threads inside the same process (like Eclipse). c. If load() finds no config file; try once more after a somewhat larger delay? (If there is a concurrent write, it might recreate the file soon.) d. In LockFile.commit(), if the atomic move fails (it may be because some other thread is currently reading the file), don't immediately delete the file but just retry. Only if it fails on the last retry, then do the delete-then- move work-around. e. In DeleteBranchCommand, do not update the git config for each branch individually. Do it once at the end, removing in one single config file update all branch configuration of branches that were successfully deleted. This will drastically reduce the potential to get such concurrent reads and writes. Also rewrite EGit's DeleteBranchOperation to call JGit's DeleteBranchCommand once for all branches. This will require the ability to set a progress monitor on the DeleteBranchCommand. Together, these might be good enough to eradicate this problem in EGit, but frankly said, it all feels like band-aid where proper surgery would be needed.
The following changes were merged: JGit: * https://git.eclipse.org/r/c/jgit/jgit/+/204919 * https://git.eclipse.org/r/c/jgit/jgit/+/204920 * https://git.eclipse.org/r/c/jgit/jgit/+/204921 * https://git.eclipse.org/r/c/jgit/jgit/+/204922 * https://git.eclipse.org/r/c/jgit/jgit/+/204923 EGit: * https://git.eclipse.org/r/c/egit/egit/+/204977 These implement my suggestions from comment 37. Closing (again) as fixed; hopefully it really is! Otherwise feel free to re-open if it re-occurs with EGit >= 6.8.0.
