Just installed Eclipse 4.3 (Kepler) which comes with EGit (which I updated to EGit 3.2.201312181205-r), and Git for Windows. I cloned a repository in the Git for Windows Bash shell under an existing Eclipse workspace, and then in Eclipse imported it as a project. However, if I right click a file that I haven't changed and select Compare With > HEAD Revision, it shows all lines as different.
In the Git for Windows bash shell, git diff on the file shows nothing. Running od -c on the file in Git bash shows it has Windows-style line endings.
When I go into Eclipse preferences for Compare/Patch and say to ignore whitespace, it shows no differences. But I'd like to understand why that is necessary.
What is really being compared here?
This is a know bug in Egit. https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
Even in Egit 3.4 (planned for June 2014) it won't be fixed. Robin Stocker gave this suggestion in the duplicate of the above bug:
Until this is implemented, I recommend this setup:
For each Eclipse project, go to Properties > Resource and change "New text file line delimiter" to Other: Unix. Commit the resulting
.settings/org.eclipse.core.runtime.prefs files.
Don't configure any .gitattributes or "core.autocrlf" for Git. This means that files will have the same line endings in the working
directory as in the repository. Git and EGit will not convert any file
contents.
With 1., all new files that are created in Eclipse will have correct
(LF) line endings, even when created by a user on Windows.
For files that are already in your repository with CRLF, you can fix
them and commit the result. I recommend using dos2unix or fromdos on
the command line.
However it's been reported that Egit ignores these settings when importing a project. https://bugs.eclipse.org/bugs/show_bug.cgi?id=421364
So it looks like all developers need to check the line endings themselves. But least you don't need any other tools to fix this. Under the File menu in Eclipse there's a: "Convert Line Delimiters To". Also note there are line ending settings for both individual projects and in the workspace settings.
For projects: right-click -> properities -> Resource
For Workspace: Window -> preferences -> General -> Workspace
Related
I'm using the Eclipse plugin for Rational Team Concert (RTC) and would like to use IntelliJ IDEA as my merge tool for resolving conflicts in incoming changes. I've already set Eclipse to use IntelliJ as its external compare tool:
When I open files with conflicts from Eclipse (e.g. from incoming changesets), they do open inside the IntelliJ merge tool. But after I make changes and select "Resolve as merged" in Eclipse, I get the error
The file has not been merged. You can open a compare editor and do the merge, or resolve with mine or proposed.
This happens regardless of whether I use the » (apply) and ✕ (ignore) GUI buttons or type/paste changes directly into the result pane.
I found a sort-of-workaround that might help with diagnosis: Eclipse RTC will sometimes accept merges after they've been attempted multiple times, or if the file is opened with "Open in External Compare Tool" from the context menu instead of by double-clicking the file name. But both of these methods are highly inconsistent, at best.
I know external merging is supposed to work because others on my team are doing it with no problems. I don't see any differences between my settings and theirs, though. Maybe I'm just not looking in the right place? I've checked under Preferences > Team > Jazz Source Control > External Compare Tool.
How can I get Eclipse RTC to understand when merges have been done, and let me select "Resolve as Merged" after manually merging in IntelliJ?
Following "Merging files using IntelliJ IDEA as a command line tool"
Type the following command at the command prompt:
<IntelliJ IDEA launcher(Windows) or wrapper script (MacOS or UNIX)>
merge <path to file1> <path to file2> <path to file3> <path to output>
where:
file1 is your local copy,
file2 is the repository version,
file3 is the base revision for file1 and file2, and
output is the file to save the merge results in (optional).
So in your case, try and invert the order for file2 and file1.
For some days now Ecplise (Oxygen 4.7.1a) shows me question marker icons at all folders and files in the project explorer.
I figured out that this is caused by a broken SVN synchronization. Eclipse error log shows The SVN synchronization information for 'Project' has become corrupt or does not exist.
I use Subclipse (latest version) from Eclipse market place.
I tried:
removing and reinstalling Subclipse
removing workspace and check out SVN repo again
Still the same problem.
The curious thing is that SVN connection is ok. I can use Tortoise SVN in Windows explorer and SVN command line, but Subclipse in Eclipse does not work.
Any solutions to this?
I had the same. I tried the one thing in the link recommended by howlger, namely:
"Close Eclipse. Open your workspace folder and then navigate to:
.metadata\.plugins\org.eclipse.core.resources\.projects
There will be a folder for each project, each will have a file named .syncinfo
in it. Delete all of these files and restart Eclipse."
It did not help. But then I tried "Add to Version Control". It complained that the project is already under Version Control, but the question mark is gone and everything seems to work OK now.
I'm working with Eclipse Mars, on Windows 7 64 bits and I recently discovered that when I clone a repository using eclipse built-in git clone feature, CRLF are not added to the files, and they are cloned with only LF at the end.
I checked Eclipse config for Git (Team > Git > Configuration) and I found that System Settings is empty and all buttons disabled and it says "Unknown" in the Location field.
I have Git for Windows 2.5.0 64 bits installed. Apparently now the system gitconfig file should be under C:\Program Files\Git\mingw64\etc but by default there is no file there.
I discovered that if I manually populate it from cmd (git config --system core.autocrlf true) it will be created, but still can't select it from Eclipse.
You need to tell EGit where the default system configuration is for it to be able to pick up the values. There's a Browse button which should allow you to change it according to the help pages:
https://wiki.eclipse.org/EGit/User_Guide#Pointing_out_the_System_wide_configuration
You can also set this property in the User Settings which Eclipse will respect. Global is 'for all users of this machine' and User Settings is typically stored in your home directory, i.e. 'for just this user'.
You'd have to find where the file that's being created by git config --global on your setup is. It's likely that git isn't on the path, and that's why Eclipse can't auto-guess where it should be.
By the way, unless you really, really need to have CRLF on the files you should prefer to keep them as how they are stored remotely - it will be faster for EGit and Git to perform deltas if it doesn't have to do line-ending conversion on most operations.
I had a similar problem so let me add this for clarification: in Eclipse Preferences > Team > Git > Configuration the System Settings Tab was empty and "Location:" said "Unknown". The EGit User Guide (https://wiki.eclipse.org/EGit/User_Guide#Pointing_out_the_System_wide_configuration) tells that "If you selected one of the options to use Git from the Command Line Prompt when you installed Git for Windows, then the location of the system wide settings is filled in with a path and everything is fine. If not, use the Browse button to locate where Git is installed, e.g. C:\Program Files(x86)\Git." Indeed I did not select the option to use "Git from the Command line ..." when I installed Git. But instead of a "Browse" button my Eclipse 2020-09 has an "Open" button and that one was GREYED OUT, so I was unable to tell EGit in the above mentioned "System Settings" Tab where the local Git installation could be found. Furthermore I did not know which path precisely had to be added to the systems PATH variable.
I then reinstalled Git with the option to use "Git from the Command line ..." and found out that "C:\Program Files\Git\cmd" was added to the System PATH. After a restart of Eclipse the "System Settings" Tab had the "Location" configured as: "C:\Program Files\Git\etc\gitconfig" and all the missing keys and corresponding values were set.
I'm running Eclipse - Indigo and have a project configured for EGit that uses Gradle to build. Today I noticed in the Package Explorer of eclipse, the build.gradle file now has a little red slash through its icon:
Where did the little red slash come from and what does it mean? Is it an egit thing (I don't think so, the file doesn't show up in git status from the command line nor does this red slashy icon appear in Preferences, Team, Git, Label Decorations)? I never noticed it before today, which leads me to believe that it hasn't showed up until today.
EDIT: Is there any chance .gitignore is contributing to confusion in eclipse? Here's the contents of my .gitignore
/test-output
/logs
# Gradle
.gradle
/build
# OSX
.DS_Store
# Eclipse
.classpath
.project
.tomcatplugin
.settings/
/work
/bin
# Emacs backup files
*~
\#*\#/bin
The red slash is a Groovy-Eclipse thing. It means that the gradle build file is being interpreted as a groovy file, but this groovy file is not on the build path (and this makes sense because gradle build files are not typically in source folders).
Is something not working, or are you just curious about the overlay?
I have checked in a huge Eclipse project from my desktop computer to the SVN server. I did it using the command line. However, by mistake I committed all the compiled classes also in the server.
For every plug-in, there is a directory /bin/ that contains the compiled classes.
Is there a way to quickly delete in the server all directories that match this pattern using the command line?
Additionally, is there a way to tell svn to ignore bin directories by default?
From here (for the 'additionally part'):
Click on Window -> Preferences
Select Team -> Ignored Resources
Click on Add Pattern and enter "bin"
Click on Apply and then OK
For the bin directories, do you have svn 1.5 ?
Because if you do, 'svn rm --keep-local' allows to pull them from version control but not delete it from your machine.
You can do it with Tortoise (Delete (keep local))
To add to what VonC suggests, if you're using the command line, you can edit your configuration file (and change your global-ignores entry) here:
~/.subversion/config
or in the windows registry:
HKCU\Software\Tigris.org\Config