Community
Participate
Working Groups
The following warning keeps appearing in my workspaces. Warning: The environment variable HOME is not set. The following directory will be used to store the Git user global configuration and to define the default location to store repositories: 'C:\Users\Edward'. If this is not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and EGit might behave differently since they see different configuration options. This warning can be switched off on the Team > Git > Confirmations and Warnings preference page. I only half understand the message. I presume you mean Window -> Preferences -> Team ... since Team -> only exists with inadequate sun content in context menus. a) I only use EGIT so I couldn't care less. b) why no quickfix to silence the warning c) HOME is not a Windows environment variable so why no fallback to HOMEPATH or rather why question the fallback d) if there really is a native git compatibility issue why no JNI API call to share the functionality in use by native git? Bottom line. This warning should not appear. EGIT should work correctly out-of-the-box. Configuration should be for irregular use.
The code below may be used in JUnit tests cases to avoid console clutter and consequential test fails. (from GIT\org.eclipse.ocl\tests\org.eclipse.ocl.examples.xtext.tests\src\org\eclipse\ocl\examples\xtext\tests\TestUIUtil.java) private static boolean testedEgitUiBundle = false; /** * Suppress diagnostics from EGIT * <p> * This was originally necessary to eliminate a model PopUp that locked up the tests (Bug 390479). * <p> * Now it just suppresses a Console Log entry. */ public static void suppressGitPrefixPopUp() { if (!testedEgitUiBundle) { testedEgitUiBundle = true; Bundle egitUiBundle = Platform.getBundle("org.eclipse.egit.ui"); if (egitUiBundle != null) { try { Class<?> activatorClass = egitUiBundle.loadClass("org.eclipse.egit.ui.Activator"); Class<?> preferencesClass = egitUiBundle.loadClass("org.eclipse.egit.ui.UIPreferences"); Method getDefaultMethod = activatorClass.getMethod("getDefault"); AbstractUIPlugin activator = (AbstractUIPlugin) getDefaultMethod.invoke(null); IPreferenceStore store = activator.getPreferenceStore(); Field field = preferencesClass.getField("SHOW_GIT_PREFIX_WARNING"); String name = (String)field.get(null); store.setValue(name, false); field = preferencesClass.getField("SHOW_HOME_DIR_WARNING"); name = (String)field.get(null); store.setValue(name, false); } catch (Exception e) {} // Ignore } } }
You should still follow its advice, to make sure your git config ends on a local disk, and not on a network share (as I have seen and experienced in several big company networks, where the Windows user data is mapped to some personalized share). Otherwise every egit operation may be slower than normal by orders of magnitude, depending on your current network connection (e.g. VPN from the other end of the world).
Your message just confuses me even more by bringing in a complete different reason. It seems a significant concern, but it is a per-repo problem. When I create a repo the dialog gives me an option to locate the new repo. The warning seems to be about the default that I usually override, when perhaps you should be checking the configured actual location to warn about repos on shared disks. Certainly, if the warning is that the dialog default is unsafe, the warning should not appear until the dialog is created, and should occur on every dialog creation. It seems very wrong that a boring Eclipse usage that uses only pre-existing repos should get a warning. Surely there is a .lock file that should inhibit actual sharing of repos? A repo on a shared disk is then perfectly safe, just irritating for those hoping for concurrency. A 'close repo' which I have previously requested to release UI resources seems very important for this use case to allow one 'concurrent' usage to yield to another. I still do not understand the appropriateness of the message I just do my best to suppress it. I am not prepared to define environment variables that may affect other tools for the unexplained convenience of some seemingly broken Eclipse functionality. Please provide answers to b), c), d) in my original comment.
