Community
Participate
Working Groups
The commit introduced in http://git.eclipse.org/c/egit/egit.git/commit/?id=7545e66c83f54777e06db05390854939e925fdce (which added the GitPrefixWarning message "EGit could not detect where Git is installed") throws a dialog in your face when starting Eclipse on a Windows platform when EGit is installed, even if the user has no EGit related projects installed. This leads problems when embedding EGit into custom distributions, because the end user may not actually be using EGit at the time. It also blocks automated testing scripts which boot up an install that are perplexed when a Modal dialog presents it with a choice that it has no knowledge of or ability to change. Furthermore, if there isn't a native Git installed, then the value of the 'auto.corelf' field (only just added to EGit) has no effect - yet this dialog is still shown. At best, this should be a warning logged to the error log of Eclipse - that way, users who are interested in seeing and resolving this message can, without having an in-your-face dialog that only serves to annoy those users who have no choice but to use a Windows operating system. There should never be areason why a Dialog needs to be shown to a user at applciations tartup. The code is in ConfigurationChecker, in the 'checkGitPrefix()' method: + if (!hidden) { + if (FS.DETECTED.gitPrefix() == null) { + MessageDialogWithToggle dialog = MessageDialogWithToggle + .openInformation( + PlatformUI.getWorkbench() + .getActiveWorkbenchWindow().getShell(),
draft for patch: https://git.eclipse.org/r/#/c/8089/
Duplicate of bug 390479?
Also see bug 390888.
*** Bug 390479 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > *** Bug 390479 has been marked as a duplicate of this bug. *** Which makes the important point. The ConfigurationChecker should not run until it is clear that GIT is being used. A JUnit test has not normally demonstrated this so clearly ConfigurationChecker is not being run in the traditional lazy Eclipse usage mode. Therefore not only the popup but the invocation context that makes the call should be fixed so that it is lazy. No GIT costs until GIT in use.
(In reply to comment #5) > (In reply to comment #4) > > *** Bug 390479 has been marked as a duplicate of this bug. *** > > Which makes the important point. > > The ConfigurationChecker should not run until it is clear that GIT is being > used. A JUnit test has not normally demonstrated this so clearly > ConfigurationChecker is not being run in the traditional lazy Eclipse usage > mode. > > Therefore not only the popup but the invocation context that makes the call > should be fixed so that it is lazy. No GIT costs until GIT in use. Not just "use", but use the setting that the dialog asks to be set. Just as a background info: currently the most common trigger to load EGit and show the dialogs is the the Git label decorator (e.g. in the Package Explorer).
(In reply to comment #6) > Just as > a background info: currently the most common trigger to load EGit and show > the dialogs is the the Git label decorator (e.g. in the Package Explorer). Ahh. My JUnit plugin tests stall at about 95% which is when a Project is created and populated, and consequently icons are being decorated. But since it was a very minimal project, the does-the-project-have-a-git-repository test should guard any serious GIT activation.
(In reply to comment #1) > draft for patch: https://git.eclipse.org/r/#/c/8089/ Merged this change into master: http://git.eclipse.org/c/egit/egit.git/commit/?id=0d264c63788cd6607fe3a83c62f6af5e2d85bc7d
The whole point of these warnings were to get in the face of the user and alert them that things will not work as expected BEFORE they make the mistakes. If it is not a dialog nobody will see it and there is no point in checking at all.
(In reply to comment #9) > The whole point of these warnings were to get in the face of the user and > alert them that things will not work as expected BEFORE they make the > mistakes. If it is not a dialog nobody will see it and there is no point in > checking at all. I agree that a dialog would be more visible but then it should only appear at the point where the corresponding information is really needed. Currently, it e.g. checks when the decorator code is invoked on a simple unshared project and that was causing a very bad user experience.
This is the wrong fix.
Let's get the background to this right. It was the very eager Dialog introduced without any cross-project dev notification at SR1 that was not the correct fix. It caused serious regressions. GIT needs to stop assuming it is the Eclipse platform. Why does GIT still insist on having a passphrase when using a CVS repo? Losing the inappropriate SR1 Dialog just gets us back to existing behaviour. Someone can now set about developing a warning that only activates when the system is actually in danger of using the questionable behaviour. Then this can be field tested, so that users can review the instruction to see whether it actually enables them to understand what the Dialog says. I keep keep clicking on the tick box but I still seem to get the popup and I cannot find the referenced preference and I wasted time developing code to shut GIT up in my tests. Grrrr. [Ironically I have cygwin installed on my Windows machine, but because I minimize PATH polution, the diagnostics are even stranger to me. Where is the ability to configure my cygwin location?]
(In reply to comment #11) > This is the wrong fix. It is much better than what we had before and the bug as reported is fixed. If you think the dialogs really important and that they can be brought back at more reasonable places and for sure not when starting Eclipse, then this can be requested in a new bug. NOTE: A good place for the dialogs could be when adding/cloning the first repository or when opening a Git preference page.
Verified in 2.2.0.201210181014.
(In reply to comment #12) > Let's get the background to this right. It was the very eager Dialog > introduced without any cross-project dev notification at SR1 that was not > the correct fix. It caused serious regressions. GIT needs to stop assuming > it is the Eclipse platform. It wasn't the intention to cause problem, but people had issue with not knowing that EGit didn't see their settings. > Why does GIT still insist on having a passphrase > when using a CVS repo? Have you reported it as a bug? > Losing the inappropriate SR1 Dialog just gets us back to existing behaviour. > > Someone can now set about developing a warning that only activates when the > system is actually in danger of using the questionable behaviour. > > Then this can be field tested, so that users can review the instruction to > see whether it actually enables them to understand what the Dialog says. I > keep keep clicking on the tick box but I still seem to get the popup and I > > cannot find the referenced preference and I wasted time developing code to > shut GIT up in my tests. Grrrr. That's a bug for sure and should be fixable by itself. Don't wait with reporting bugs so we get a chance to fix them properly. The dialog commit was merged after 2.0 to give people plenty of time to discover issues with it before the next release. SR1 came three months later. > [Ironically I have cygwin installed on my Windows machine, but because I > minimize PATH polution, the diagnostics are even stranger to me. Where is > the ability to configure my cygwin location?] It doesn't care whether Git is installed from Git for Windows or a cygwin package, Tortoise or whatever. Cygwin should work too. I know there have been issues with auto detection for cygwin, but manual config did work last time I checked. Cygwin path translation is too slow to be usable so there are compatibility issues with cygwin.
(In reply to comment #15) > > Why does GIT still insist on having a passphrase > > when using a CVS repo? > > Have you reported it as a bug? Yes. Bug 351106. > > cannot find the referenced preference and I wasted time developing code to > > shut GIT up in my tests. Grrrr. > > That's a bug for sure and should be fixable by itself. Yes. Bug 390888. > Don't wait with reporting bugs so we get a chance to fix them properly. You can see I've already winged quite a bit. When searching for duplicates one can get a bit discouraged by the number of Open bugs. I tend to take the view that EGIT has so many known bugs, it is difficult to find a new one. > The dialog commit was merged after 2.0 to give people plenty of time to discover issues with it before the next release. SR1 came three months later. This succeeded in bypassing our Hudson testing, since with minimal plugins there is no problem. It was not distributed as part of M1 or M2. Unfortunately EGIT does not publish builds in traditional Eclipse (Modeling) fashion, so it is very difficult to use early releases. I expect to be able to download a clearly named Update ZIP so that I know exactly what I'm doing. I expect to find this by following the Downloads link on http://www.eclipse.org/projects/project.php?id=technology.egit. https://bugs.eclipse.org/bugs/show_bug.cgi?id=364685#c6 The nightly repos, while critical, are not listed on the project page.
(In reply to comment #16) > Unfortunately EGIT does not publish builds in traditional Eclipse (Modeling) > fashion, so it is very difficult to use early releases. I expect to be able > to download a clearly named Update ZIP so that I know exactly what I'm > doing. I expect to find this by following the Downloads link on > http://www.eclipse.org/projects/project.php?id=technology.egit. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=364685#c6 > > The nightly repos, while critical, are not listed on the project page. I don't know what the traditional Eclipse (Modeling) fashion is. What should the Update ZIP contain you are missing ? The nightly repos are listed here http://www.eclipse.org/egit/download/ this page is linked from http://www.eclipse.org/egit/ and also listed as "Downloads URL" in the project's meta data AFAIK http://www.eclipse.org/projects/project.php?id=technology.egit is generated from the project's meta data maintained in the portal and I don't know how to change its section "Software Repository" so that it links to the download page.
(In reply to comment #17) > AFAIK http://www.eclipse.org/projects/project.php?id=technology.egit is > generated from the project's meta data maintained in the portal and I don't > know how to change its section "Software Repository" so that it links to the > download page. Correct. See here: http://wiki.eclipse.org/Development_Resources/HOWTO/Project_Meta-Data
(In reply to comment #17) > I don't know what the traditional Eclipse (Modeling) fashion is. What should > the Update ZIP contain you are missing ? See e.g http://www.eclipse.org/modeling/emf/downloads/?project=emf where there is an All-In-One Update site for a wide variety of versions including N-builds (when there are some). The Update ZIP should be droppable onto the Install New Software dialog. IMHO P2 has rendered many of the other artefacts obsolete. But the All-In-One is invaluable. (In reply to comment #18) > (In reply to comment #17) > > AFAIK http://www.eclipse.org/projects/project.php?id=technology.egit is > > generated from the project's meta data maintained in the portal and I don't > > know how to change its section "Software Repository" so that it links to the > > download page. > > Correct. > > See here: > http://wiki.eclipse.org/Development_Resources/HOWTO/Project_Meta-Data Bug 393104 raised
*** Bug 394117 has been marked as a duplicate of this bug. ***
I see two EGit pop-ups on startup with EGit 2.1 and no EGit functionality used (empty workspace, no EGit views). Could someone confirm that this fix eliminates both of the dialogs?
(In reply to comment #21) > I see two EGit pop-ups on startup with EGit 2.1 and no EGit functionality > used (empty workspace, no EGit views). Could someone confirm that this fix > eliminates both of the dialogs? Yes. I suggest you switch to a nightly build. They work fine for me.
Our product is now set to ship built against 3.8.1 and now this dialog is annoying our customers (many do not use git, and basically +1 to everything said here). I'd like to understand: Does 3.8.1 have any suppressing mechanism available to us to suppress its dialog? Is this fixed such that 3.8.2 will not need any workaround I develop?
(In reply to comment #23) > Our product is now set to ship built against 3.8.1 and now this dialog is > annoying our customers (many do not use git, and basically +1 to everything > said here). > > I'd like to understand: > > Does 3.8.1 have any suppressing mechanism available to us to suppress its > dialog? The user can disable the warnings on the 'Confirmation Dialogs' preference page. If that's not enough you can ship your product with some default preferences. In that preference file you can disable the dialogs: 1. Put this into the file: org.eclipse.egit.ui/show_home_drive_warning=false org.eclipse.egit.ui/show_git_prefix_warning=false 2.Add this to the command line when starting Eclipse / your product: -pluginCustomization full_path_to_file > Is this fixed such that 3.8.2 will not need any workaround I develop? I don't know whether EGit updates to the latest version in SR2. Matthias?
(In reply to comment #24) > (In reply to comment #23) > > Is this fixed such that 3.8.2 will not need any workaround I develop? > I don't know whether EGit updates to the latest version in SR2. Matthias? EGit 2.2 is planned to be released Dec 19, 2012, 2.3 will be shipped with 4.2 SR2 in Feb 2012
