[EGIT PATCH] Support linked resources

I have a project that outputs to a linked directory (for example the
project is in /projects/foo and the project outputs to /projects/bar).
This was causing egit to throw a bunch of "file is not in working
path" errors whenever I rebuilt the project or otherwise interacted
with that linked directory. I tracked it down to GitIndex's add/remove
being called on these files even though these files are not part of
the actual index.

It seems like egit shouldn't be trying to interact with the index on
these files, and after looking at it, I decided the best solution
would be to realize in the RepositoryMapping that these files do not
point to a repository.

I wasn't sure what the best solution for deciding if a file was in the
same location as the project it is referenced in, but I somewhat
modeled it off of the way GitIndex's makeKey does its validation.

Patch:
Fixed 'Path is not in working directory' error for linked resources

Signed-off-by: Reg Vos <redacted>
---
 .../egit/core/project/RepositoryMapping.java       |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java

b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
index 6a0b56f..5863a49 100644

--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java

@@ -236,6 +236,8 @@ public class RepositoryMapping {
 		IProject project = resource.getProject();
 		if (project == null)
 			return null;
+		if (!project.getLocation().isPrefixOf(resource.getLocation()))
+			return null;
 		RepositoryProvider provider = RepositoryProvider.getProvider(project);
 		if (!(provider instanceof GitProvider))
 			return null;

-- 
1.5.4.2

torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:

I have a project that outputs to a linked directory (for example the
project is in /projects/foo and the project outputs to /projects/bar).
This was causing egit to throw a bunch of "file is not in working
path" errors whenever I rebuilt the project or otherwise interacted
with that linked directory. I tracked it down to GitIndex's add/remove
being called on these files even though these files are not part of
the actual index.

It seems like egit shouldn't be trying to interact with the index on
these files, and after looking at it, I decided the best solution
would be to realize in the RepositoryMapping that these files do not
point to a repository.

I'd be inclined to prefer ignoring any non-plain resource, always. Linked
resources are either absolute or relative to a variable. Other than that 
there is an analogy to symbolic links. Git manages the link, not its
content (unless handled elsewhere). The link in this case is in the
.project file and thus managed there.

EGit could still managed the resource, but not via the link, but rather at
the place it is located, iff that happens to be in a project managed by Egit.

-- robin

Robin Rosenberg [off-list ref] wrote:

torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:

quoted

I have a project that outputs to a linked directory (for example the
project is in /projects/foo and the project outputs to /projects/bar).

...

I'd be inclined to prefer ignoring any non-plain resource, always. Linked
resources are either absolute or relative to a variable. Other than that 
there is an analogy to symbolic links. Git manages the link, not its
content (unless handled elsewhere). The link in this case is in the
.project file and thus managed there.

EGit could still managed the resource, but not via the link, but rather at
the place it is located, iff that happens to be in a project managed by Egit.

My last day-job used a project layout in the filesystem of:

	GIT_REPO/
	  .git/
      .gitignore
      _eclipse_projects/
          com.sekret.foo/.project
          com.sekret.bar/.project
      foo/
          com/sekret/foo/Foo.java
      bar/
          com/sekret/bar/Bar.java

The two .project files contained links called "src" to "foo" and
"bar" respectively.  The _eclipse_projects folder is ignored by
.gitignore, and the .project files were actually generated on the
fly by our non-Eclipse based buildsystem.

Consequently I wanted egit to be able to manage the stuff inside of
a linked folder, so long as it mapped onto the same repository that
the project mapped onto.  Without that the "src" folder contents
wouldn't be available to egit, and egit would be more-or-less
useless on this sort of layout.

-- 
Shawn.