Community
Participate
Working Groups
As the result, in case when "git" command isn't available on Mac, it provoke window similar to this: https://i.stack.imgur.com/7O1N9.png
JGit tries to figure out the location of the system-wide git config. Since that location is undefined, it calls GIT_EDITOR=echo git config --system --edit which will print the location. Now the Mac has this fancy dummy git that, unless the Xcode command-line tools have been installed, prompts you to do so. Installing the Xcode command-line tools will then install a real git. I don't know of a way to find the git system config that doesn't involve calling git. So I have no idea how we could avoid that. Short of not even trying to find the system-wide git. Is there any way to figure out in a simple way whether the git executable found is a real git or this Xcode wrapper?
Maybe solution from here: https://github.com/docksal/docksal/issues/1003
That might indeed give us a way to avoid that stupid prompt. I had already noticed that the wrapper remains even after the Xcode tools are installed. Normal (non-Apple) git gets installed in /usr/local/bin, but that is after /usr/bin on the path. Changing the $PATH in a terminal (for instance in .profile) doesn't change the $PATH for applications started via the GUI. So on Mac we either say there's no git installed if that xcode incantation tells us that there's no xcode git, or we additionally check for /usr/local/bin/git and use that if it exists.
what a mess If git is installed using homebrew it's also linked from /usr/local/bin/git so it looks like this strategy should work.
macports would probably install or link it as /opt/local/bin/git. Another alternative to try to find git to try to find the system config is to make the location of the system git config settable from outside (new JGit API). Then we can in EGit add a preference for it and let the user specify the path if we can't figure it out ourselves.
(In reply to Matthias Sohn from comment #4) > what a mess > > If git is installed using homebrew it's also linked from /usr/local/bin/git > so it looks like this strategy should work. For brew, which git return correct location. Someone can check macports? So if works similar, when which git return /usr/bin/git, method from GitHub should be used to detect dummy file.
on Mac we could also try to get these alternative installation paths by running $ which git
FS_POSIX.discoverGitExe does that on Mac; it runs bash --login -c 'which git' which should find such a non-Apple git if the $PATH in bash has /usr/local/bin or /opt/local/bin before /usr/bin. However, we first try to find it on $PATH directly. So on Mac we need to do something like gitExe = findOnPath() if (gitExe == null || "/usr/bin/git".equals(gitExe)) { gitExe = findViaBash() } if ("/usr/bin/git".equals(gitExe)) { // Check via xcode-select, set to null if xcode not installed }
@Dawid: I can try to fix this via this xcode-select, but unfortunately I have no Mac on which the Xcode command-line tools are not installed, so I won't be able to test. If I push a fix attempt, could you test it?
(In reply to Thomas Wolf from comment #9) > @Dawid: I can try to fix this via this xcode-select, but unfortunately I > have no Mac on which the Xcode command-line tools are not installed, so I > won't be able to test. If I push a fix attempt, could you test it? I already installed command line utils, but I can easy prepare parallels virtual machine witch fresh macOS.
New Gerrit change created: https://git.eclipse.org/r/165220
(In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/165220 I managed to set up a VirtualBox OS X (10.14) guest and install AdoptOpenJDK 11.0.7 and Eclipse for Java Developers 2020-06 in it. 1. xcode-setup -p exits with error code 2 if XCode isn't installed at all. 2. Eclipse indeed causes that dialog on each start, but continues to launch. 3. Updating EGit in that OS X guest to EGit nightly and then updating JGit from the above build's repo (downloaded as zip, URL is [1]) indeed solves the problem: Eclipse starts without causing that dialog. 4. At the same time, Eclipse using a JGit with the above patch running on my OS X host (which does have the XCode tools installed) works fine, too. I didn't do any further checks (like verifying that if I install in the OS X guest the git from [2] and update the bash $PATH to use that, Eclipse picks up that one) because this OS X guest doesn't work right; it's super slow (much slower than my CentOS7 guest) and keeps losing the mouse and keyboard input for extended periods of time, so it's not really usable. Just setting up the VM took hours, and installing and updating Eclipse and verifying it avoids the prompt took a couple hours more :-( So it'd still be good if Dawid could test a little more and confirm. [1] https://ci.eclipse.org/jgit/job/stable/job/jgit.gerrit-pipeline/3333/artifact/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository/*zip*/repository.zip [2] https://sourceforge.net/projects/git-osx-installer/
I prepared fresh machine with AdoptJDK 11 and Eclipse PHP 2020-06. After install EGIT 5.9 (from nightly) and JGIT from linked repository annoying popup gone. Later I installed git form git-osx-installer, it become available in Terminal.app (`which git` result is /usr/local/bin/git) but not in eclipse. After eclipse restart annoying popup was back. Reboot didn't help.
Yeah, of course. Because after having determined the installed git, JGit just calls "git" instead of actually using the path it found! Yuck. Update a-coming.
Dawid, could you try again after updating to the JGit from [1]? This one should work now whether no git is installed at all, non-Apple git, or Apple git, and should never cause the XCode prompt. Unless there's still other places where JGit just calls plain "git". But AFAIK this is the only place. [1] https://ci.eclipse.org/jgit/job/stable/job/jgit.gerrit-pipeline/3334/artifact/*zip*/archive.zip
(In reply to Thomas Wolf from comment #15) > https://ci.eclipse.org/jgit/job/stable/job/jgit.gerrit-pipeline/3334/ > artifact/*zip*/archive.zip I meant of course https://ci.eclipse.org/jgit/job/stable/job/jgit.gerrit-pipeline/3334/artifact/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository/*zip*/repository.zip
Managed to verify in three VirtualBox VMs: OS X Mojave, OS X HighSierra, and Windows 10. (The latter included to check that the change in FS.java didn't break anything.) On OS X works now as intended, never triggers the XCode prompt, and picks up a non-Apple git if set in the bash $PATH, and still works with the Apple git if the XCode tools are installed (and first on the bash $PATH). Off-topic: Mojave isn't supported yet by VirtualBox, only HighSierra is. HighSierra works marginally better, but the lack of GPU support in the VM means mouse pointer tracking is laggy when there are animations or SWT dialogs. With Mojave, mouse pointer tracking just seems to stop completely. So neither VM is really useable. (I can understand the animations part, but SWT dialogs? Is SWT doing something that needs a lot of GPU all the time?)
I'll test it tomorrow. (In reply to Thomas Wolf from comment #17) > Off-topic: Mojave isn't supported yet by VirtualBox, only HighSierra is. > HighSierra works marginally better, but the lack of GPU support in the VM > means mouse pointer tracking is laggy when there are animations or SWT > dialogs. With Mojave, mouse pointer tracking just seems to stop completely. > So neither VM is really useable. (I can understand the animations part, but > SWT dialogs? Is SWT doing something that needs a lot of GPU all the time?) Yeah, on Mac SWT is often clumsy, and consume a lot of GPU. It invalidate entire widget for every single change. Canvas use own scrolling, rather than cocoas one. I'm also afraid that because SWT consume all events (event if they are not used), this introduce additional overhead.
(In reply to Dawid Pakula from comment #18) > (In reply to Thomas Wolf from comment #17) > > Off-topic: Mojave isn't supported yet by VirtualBox, only HighSierra is. > > HighSierra works marginally better, but the lack of GPU support in the VM > > means mouse pointer tracking is laggy when there are animations or SWT > > dialogs. With Mojave, mouse pointer tracking just seems to stop completely. > > So neither VM is really useable. (I can understand the animations part, but > > SWT dialogs? Is SWT doing something that needs a lot of GPU all the time?) > > Yeah, on Mac SWT is often clumsy, and consume a lot of GPU. It invalidate > entire widget for every single change. Canvas use own scrolling, rather than > cocoas one. I'm also afraid that because SWT consume all events (event if > they are not used), this introduce additional overhead. So far it only seems to be dialogs and the built-in web browser. Text editing works in Eclipse in the VM. Not quite as fast as in my Linux VM, but useable.
(In reply to Dawid Pakula from comment #18) > I'll test it tomorrow. Dawid, did you have time to test this?
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/165220 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=9fe54061197c42faedc9417bdc70797681aa06d6
