{"thread":{"id":"14650","subject":"[EGIT PATCH] Support linked resources","startedAt":"2008-07-24T03:34:06Z","lastAt":"2008-07-26T21:59:12Z","messageCount":3,"participants":["Richie Vos","Robin Rosenberg","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"84668","messageId":"5a27b7b0807232034t564e8d45l9f6e4bc6429cda60@mail.gmail.com","threadId":"14650","inReplyTo":null,"subject":"[EGIT PATCH] Support linked resources","fromName":"Richie Vos","fromEmail":"jerry.vos@gmail.com","sentAt":"2008-07-24T03:34:06Z","receivedAt":"2008-07-24T03:34:06Z","isPatch":true,"sender":{"key":"jerry.vos@gmail.com","avatar":null},"body":"I have a project that outputs to a linked directory (for example the\nproject is in /projects/foo and the project outputs to /projects/bar).\nThis was causing egit to throw a bunch of \"file is not in working\npath\" errors whenever I rebuilt the project or otherwise interacted\nwith that linked directory. I tracked it down to GitIndex's add/remove\nbeing called on these files even though these files are not part of\nthe actual index.\n\nIt seems like egit shouldn't be trying to interact with the index on\nthese files, and after looking at it, I decided the best solution\nwould be to realize in the RepositoryMapping that these files do not\npoint to a repository.\n\nI wasn't sure what the best solution for deciding if a file was in the\nsame location as the project it is referenced in, but I somewhat\nmodeled it off of the way GitIndex's makeKey does its validation.\n\nPatch:\nFixed 'Path is not in working directory' error for linked resources\n\nSigned-off-by: Reg Vos <jerry.vos@gmail.com>\n---\n .../egit/core/project/RepositoryMapping.java       |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java\nb/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java\nindex 6a0b56f..5863a49 100644\n--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java\n+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java\n@@ -236,6 +236,8 @@ public class RepositoryMapping {\n \t\tIProject project = resource.getProject();\n \t\tif (project == null)\n \t\t\treturn null;\n+\t\tif (!project.getLocation().isPrefixOf(resource.getLocation()))\n+\t\t\treturn null;\n \t\tRepositoryProvider provider = RepositoryProvider.getProvider(project);\n \t\tif (!(provider instanceof GitProvider))\n \t\t\treturn null;\n-- \n1.5.4.2\n"},{"id":"85068","messageId":"200807261707.18299.robin.rosenberg.lists@dewire.com","threadId":"14650","inReplyTo":"5a27b7b0807232034t564e8d45l9f6e4bc6429cda60@mail.gmail.com","subject":"Re: [EGIT PATCH] Support linked resources","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-07-26T15:07:18Z","receivedAt":"2008-07-26T15:07:18Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:\n> I have a project that outputs to a linked directory (for example the\n> project is in /projects/foo and the project outputs to /projects/bar).\n> This was causing egit to throw a bunch of \"file is not in working\n> path\" errors whenever I rebuilt the project or otherwise interacted\n> with that linked directory. I tracked it down to GitIndex's add/remove\n> being called on these files even though these files are not part of\n> the actual index.\n> \n> It seems like egit shouldn't be trying to interact with the index on\n> these files, and after looking at it, I decided the best solution\n> would be to realize in the RepositoryMapping that these files do not\n> point to a repository.\n\nI'd be inclined to prefer ignoring any non-plain resource, always. Linked\nresources are either absolute or relative to a variable. Other than that \nthere is an analogy to symbolic links. Git manages the link, not its\ncontent (unless handled elsewhere). The link in this case is in the\n.project file and thus managed there.\n\nEGit could still managed the resource, but not via the link, but rather at\nthe place it is located, iff that happens to be in a project managed by Egit.\n\n-- robin\n"},{"id":"85123","messageId":"20080726215912.GD16219@spearce.org","threadId":"14650","inReplyTo":"200807261707.18299.robin.rosenberg.lists@dewire.com","subject":"Re: [EGIT PATCH] Support linked resources","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-26T21:59:12Z","receivedAt":"2008-07-26T21:59:12Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:\n> torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:\n> > I have a project that outputs to a linked directory (for example the\n> > project is in /projects/foo and the project outputs to /projects/bar).\n...\n> I'd be inclined to prefer ignoring any non-plain resource, always. Linked\n> resources are either absolute or relative to a variable. Other than that \n> there is an analogy to symbolic links. Git manages the link, not its\n> content (unless handled elsewhere). The link in this case is in the\n> .project file and thus managed there.\n> \n> EGit could still managed the resource, but not via the link, but rather at\n> the place it is located, iff that happens to be in a project managed by Egit.\n\nMy last day-job used a project layout in the filesystem of:\n\n\tGIT_REPO/\n\t  .git/\n      .gitignore\n      _eclipse_projects/\n          com.sekret.foo/.project\n          com.sekret.bar/.project\n      foo/\n          com/sekret/foo/Foo.java\n      bar/\n          com/sekret/bar/Bar.java\n\nThe two .project files contained links called \"src\" to \"foo\" and\n\"bar\" respectively.  The _eclipse_projects folder is ignored by\n.gitignore, and the .project files were actually generated on the\nfly by our non-Eclipse based buildsystem.\n\nConsequently I wanted egit to be able to manage the stuff inside of\na linked folder, so long as it mapped onto the same repository that\nthe project mapped onto.  Without that the \"src\" folder contents\nwouldn't be available to egit, and egit would be more-or-less\nuseless on this sort of layout.\n\n-- \nShawn.\n"}]}