Question

I'm running this on Windows Server 2003, and using the Cygwin version of the Git command line tools.

I have a Subversion repository containing a set of Eclipse projects, and am testing migration of this repository into Git. From the command line I've used git svn to create the git repository, and git clone to clone the new repository locally. In Eclipse I use the import wizard "Import->Projects from Git->Existing local repository" to import the projects from the local clone.

Once the projects have been imported, EGit shows an apparently random selection of source files as having unstaged changes. Comparing the files reveals no differences with the version in Git, and replacing the file with the HEAD revision has no effect.

Was it helpful?

Solution

Eventually after much head-scratching I tracked down the problem.

In the original Subversion repository, a number of source files had been checked in with the Subversion svn:executable property set. This property is honoured by git svn, and when the file is ultimately presented in the Git working directory it has the execute permission property set. Even though this is how the file is configured in Git, EGit looks like it isn't seeing the permission set in the repository and is treating it a difference between the repository copy and the working copy... hence it appears in the list of unstaged changes.

I fixed the issue simply using chmod -x on the affected files from the Cygwin bash shell, and committed the changes. I understand that setting the Git property core.filemode=false should also resolve the issue, although I've yet to try this.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top