{"thread":{"id":"14004","subject":"[egit-jgit] excluded patterns are decorated as being untracked","startedAt":"2008-06-17T16:43:12Z","lastAt":"2008-06-18T22:03:36Z","messageCount":5,"participants":["Galder Zamarreno","Robin Rosenberg","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"80153","messageId":"4857E9A0.7070408@redhat.com","threadId":"14004","inReplyTo":null,"subject":"[egit-jgit] excluded patterns are decorated as being untracked","fromName":"Galder Zamarreno","fromEmail":"galder.zamarreno@redhat.com","sentAt":"2008-06-17T16:43:12Z","receivedAt":"2008-06-17T16:43:12Z","isPatch":false,"sender":{"key":"galder.zamarreno@redhat.com","avatar":null},"body":"Hi,\n\nI've been using egit for a few weeks and firstly, I'd like to thank the \npeople involved in the project for the work done so far.\n\nThere's one thing that has been bugging me about egit though which is \nrelated to the decoration of untracked files. Egit/JGit does not seem to \npay attention to .git/info/exclude that I have configured so that \nanything under output folder is excluded.\n\nEgit/JGit does seem to have decorations working fine for patterns \nspecified in \"Team/Ignored Resources\" but it only applies it to files \nnot folders, hence, adding \"output\" as pattern does not work and \ninstead, I have to specify any pattern that would match a file within \nthe output folder which is not practical. Folders are taken into account \nas ignored resources in subeclipse (subversion eclipse plugin)\n\nI can see two ways of implementing this that I'm happy to have a look \ninto but I wanted to get some advice from the experts of egit/jgit to \nindicate which would be the preferred solution going forward.\n\n1.- Implement .git/info/exclude functionality in egit/jgit\n\n2.- Improve the decoration handling in jgit/egit so that it can check \nwhether the file is under a pattern that should be excluded. I tried to \nimplement this but requires using API that eclipse considers internal.\n\nWhat do people think? Should I bother with 2 or is it better to \nimplement decorations for patterns in .git/info/exclude correctly?\n\nThanks!\n-- \nGalder Zamarreño\nSr. Software Maintenance Engineer\nJBoss, a division of Red Hat\n"},{"id":"80162","messageId":"200806172316.46416.robin.rosenberg.lists@dewire.com","threadId":"14004","inReplyTo":"4857E9A0.7070408@redhat.com","subject":"Re: [egit-jgit] excluded patterns are decorated as being untracked","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-06-17T21:16:46Z","receivedAt":"2008-06-17T21:16:46Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdagen den 17 juni 2008 18.43.12 skrev Galder Zamarreno:\n> Hi,\n> \n> I've been using egit for a few weeks and firstly, I'd like to thank the \n> people involved in the project for the work done so far.\n> \n> There's one thing that has been bugging me about egit though which is \n> related to the decoration of untracked files. Egit/JGit does not seem to \n> pay attention to .git/info/exclude that I have configured so that \n> anything under output folder is excluded.\nThis is a correct observation. It is a missing feature so far.\n\n> Egit/JGit does seem to have decorations working fine for patterns \n> specified in \"Team/Ignored Resources\" but it only applies it to files \n> not folders, hence, adding \"output\" as pattern does not work and \nI haven't noticed, but looking at the code its seems some we should\nuse Team.isIgnoredHint instead of what we do now (which only\ntake a file as an argument). Patch below. The reason I haven't noticed\nis that I have only depended on Eclipse marking of resources as \"derived\"\nwhich worked. (You can mark resources as derived youself in the properties\nof that resource, and Egit will ignore it).\n\n> instead, I have to specify any pattern that would match a file within \n> the output folder which is not practical. Folders are taken into account \n> as ignored resources in subeclipse (subversion eclipse plugin)\n> \n> I can see two ways of implementing this that I'm happy to have a look \n> into but I wanted to get some advice from the experts of egit/jgit to \n> indicate which would be the preferred solution going forward.\n> \n> 1.- Implement .git/info/exclude functionality in egit/jgit\nWe need that. Florian came up with a set of patches that should be\nusable for this. I haven't applied them to the tree yet.\n\n> 2.- Improve the decoration handling in jgit/egit so that it can check \n> whether the file is under a pattern that should be excluded. I tried to \n> implement this but requires using API that eclipse considers internal.\n> \n> What do people think? Should I bother with 2 or is it better to \n> implement decorations for patterns in .git/info/exclude correctly?\n\nThe decoration should not ignore anything except what the resource filters\n(affecting visibility) dictates. If a resource is tracked it should be shown unless\nvisibility is prevented by a resource filter or other view specific mechanism.\nWhen we track (add) resources recursively we should honor the git ignore\npatterns, but only for add. Everywhere else we do not just ignore resources\nthat match an ignore pattern.\n\nBtw, Here is an attempt to match folders by Team ignore patterns too.\n\n(OT: I did not format the code. (please try, and you'll see why). We'll have\nto come up with something better than an 80-column format, it's so seventies)\n\n-- robin\n\n>From 42eadb50b9b87e5324f941ce2d2371e07577f55a Mon Sep 17 00:00:00 2001\nFrom: Robin Rosenberg \nDate: Tue, 17 Jun 2008 22:48:52 +0200\nSubject: [PATCH] Apply Team/Ignore settings to folders too when tracking new resources\n\nWe used to only care for file resources. Now folders, and their content,\nare ignored if the folder name matches a pattern marked as ignored\nin the Team settings.\n\n\nSigned-off-by: Robin Rosenberg \n---\n .../org/spearce/egit/core/op/TrackOperation.java | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\ndiff --git a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\nindex 6521f1c..af16cdb 100644\n--- a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n+++ b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n@@ -90,13 +90,20 @@ public class TrackOperation implements IWorkspaceRunnable {\n \t\t\t\t\t\t\tpublic boolean visit(IResource resource) throws CoreException {\n \t\t\t\t\t\t\t\ttry {\n \t\t\t\t\t\t\t\t\tString repoPath = rm.getRepoRelativePath(resource);\n+\t\t\t\t\t\t\t\t\t// We use add to reset the assume valid bit, so we check the bit\n+\t\t\t\t\t\t\t\t\t// first. If a resource within a ignored folder is marked\n+\t\t\t\t\t\t\t\t\t// we ignore it here, i.e. there is no way to unmark it expect\n+\t\t\t\t\t\t\t\t\t// by explicitly selecting and invoking track on it.\n \t\t\t\t\t\t\t\t\tif (resource.getType() == IResource.FILE) {\n \t\t\t\t\t\t\t\t\t\tEntry entry = index.getEntry(repoPath);\n-\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnored((IFile)resource) || entry != null && entry.isAssumedValid()) {\n+\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnoredHint(resource) || entry != null && entry.isAssumedValid()) {\n \t\t\t\t\t\t\t\t\t\t\tentry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath));\n \t\t\t\t\t\t\t\t\t\t\tentry.setAssumeValid(false);\n \t\t\t\t\t\t\t\t\t\t}\n \t\t\t\t\t\t\t\t\t}\n+\t\t\t\t\t\t\t\t\tif (Team.isIgnoredHint(resource))\n+\t\t\t\t\t\t\t\t\t\treturn false;\n+\n \t\t\t\t\t\t\t\t} catch (IOException e) {\n \t\t\t\t\t\t\t\t\te.printStackTrace();\n \t\t\t\t\t\t\t\t\tthrow Activator.error(CoreText.AddOperation_failed, e);\n-- \n1.5.5.1.178.g1f811\n"},{"id":"80201","messageId":"20080618043931.GC11793@spearce.org","threadId":"14004","inReplyTo":"200806172316.46416.robin.rosenberg.lists@dewire.com","subject":"Re: [egit-jgit] excluded patterns are decorated as being untracked","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-06-18T04:39:31Z","receivedAt":"2008-06-18T04:39:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> Btw, Here is an attempt to match folders by Team ignore patterns too.\n> \n> (OT: I did not format the code. (please try, and you'll see why). We'll have\n> to come up with something better than an 80-column format, it's so seventies)\n\nIgnoring the patch for a second, I'm a die-hard 80 column format\nperson. You can pry my 80 column wide terminals from me long after\nI'm dead.\n\nIn Java it may seem like an 80 column limit is a problem, because\nthe code often gets nested deep and far to the right, such as in\nthis example here. I find that just like in C, when code is this\nfar indented to the right in Java its too damn complex as-is and\nshould be refactored into smaller methods, and anonymous types\nshould perhaps be converted to named inner classes or top-level\nclasses of their own right.\n\nMy laptop display panel is only 1440 pixels wide. By the time I\nget my Eclipse workbench open I have about 90 characters wide for\nthe editor page, given how I place the other views and non-Eclipse\napplications around the edges. Pushing much beyond 80 characters\nwide makes it very hard to read code quickly.\n\nAnd no, I do not want to tote a laptop with a display that is 9000\npixels wide, thanks.\n\nSo IMHO, code in jgit+egit should try to target 80 characters wide\nas much as possible. If you can't hit that you need to rethink how\nyou have the code structured. I've never refactored something into\nsmaller more modular methods (to hit the 80 target) and said \"gee,\nthat refactoring made my code harder to understand, what with those\nhighly descriptive method names and javadoc I gave everything\".\n\nOK, now you can call me crazy.\n \n> diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> index 6521f1c..af16cdb 100644\n> --- a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> +++ b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> @@ -90,13 +90,20 @@ public class TrackOperation implements IWorkspaceRunnable {\n> \t\t\t\t\t\t\tpublic boolean visit(IResource resource) throws CoreException {\n> \t\t\t\t\t\t\t\ttry {\n> \t\t\t\t\t\t\t\t\tString repoPath = rm.getRepoRelativePath(resource);\n> +\t\t\t\t\t\t\t\t\t// We use add to reset the assume valid bit, so we check the bit\n> +\t\t\t\t\t\t\t\t\t// first. If a resource within a ignored folder is marked\n> +\t\t\t\t\t\t\t\t\t// we ignore it here, i.e. there is no way to unmark it expect\n> +\t\t\t\t\t\t\t\t\t// by explicitly selecting and invoking track on it.\n> \t\t\t\t\t\t\t\t\tif (resource.getType() == IResource.FILE) {\n> \t\t\t\t\t\t\t\t\t\tEntry entry = index.getEntry(repoPath);\n> -\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnored((IFile)resource) || entry != null && entry.isAssumedValid()) {\n> +\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnoredHint(resource) || entry != null && entry.isAssumedValid()) {\n> \t\t\t\t\t\t\t\t\t\t\tentry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath));\n> \t\t\t\t\t\t\t\t\t\t\tentry.setAssumeValid(false);\n> \t\t\t\t\t\t\t\t\t\t}\n> \t\t\t\t\t\t\t\t\t}\n> +\t\t\t\t\t\t\t\t\tif (Team.isIgnoredHint(resource))\n> +\t\t\t\t\t\t\t\t\t\treturn false;\n> +\n> \t\t\t\t\t\t\t\t} catch (IOException e) {\n> \t\t\t\t\t\t\t\t\te.printStackTrace();\n> \t\t\t\t\t\t\t\t\tthrow Activator.error(CoreText.AddOperation_failed, e);\n\n-- \nShawn.\n"},{"id":"80227","messageId":"48592C88.3080302@redhat.com","threadId":"14004","inReplyTo":"200806172316.46416.robin.rosenberg.lists@dewire.com","subject":"Re: [egit-jgit] excluded patterns are decorated as being untracked","fromName":"Galder Zamarreno","fromEmail":"galder.zamarreno@redhat.com","sentAt":"2008-06-18T15:40:56Z","receivedAt":"2008-06-18T15:40:56Z","isPatch":false,"sender":{"key":"galder.zamarreno@redhat.com","avatar":null},"body":"Hi,\n\nFirstly, thanks to all for the quick response.\n\nRobin Rosenberg wrote:\n> tisdagen den 17 juni 2008 18.43.12 skrev Galder Zamarreno:\n>> Hi,\n>>\n>> I've been using egit for a few weeks and firstly, I'd like to thank the \n>> people involved in the project for the work done so far.\n>>\n>> There's one thing that has been bugging me about egit though which is \n>> related to the decoration of untracked files. Egit/JGit does not seem to \n>> pay attention to .git/info/exclude that I have configured so that \n>> anything under output folder is excluded.\n> This is a correct observation. It is a missing feature so far.\n> \n>> Egit/JGit does seem to have decorations working fine for patterns \n>> specified in \"Team/Ignored Resources\" but it only applies it to files \n>> not folders, hence, adding \"output\" as pattern does not work and \n> I haven't noticed, but looking at the code its seems some we should\n> use Team.isIgnoredHint instead of what we do now (which only\n> take a file as an argument). Patch below. The reason I haven't noticed\n> is that I have only depended on Eclipse marking of resources as \"derived\"\n> which worked. (You can mark resources as derived youself in the properties\n> of that resource, and Egit will ignore it).\n\nHmmmm, is marking a resource as \"derived\" recursive? i.e. if I mark \n\"output\" folder as derived, would anything under it be considered \nderived? It'd be a pain to go a mark as derived each and every class.\n\nI suppose you still need the patch to use Team.isIgnoredHint to get \nderived resources to be ignored, correct?\n\n> \n>> instead, I have to specify any pattern that would match a file within \n>> the output folder which is not practical. Folders are taken into account \n>> as ignored resources in subeclipse (subversion eclipse plugin)\n>>\n>> I can see two ways of implementing this that I'm happy to have a look \n>> into but I wanted to get some advice from the experts of egit/jgit to \n>> indicate which would be the preferred solution going forward.\n>>\n>> 1.- Implement .git/info/exclude functionality in egit/jgit\n> We need that. Florian came up with a set of patches that should be\n> usable for this. I haven't applied them to the tree yet.\n\nThat'd probably be the proper solution to the decoration issue at hand.\n\n> \n>> 2.- Improve the decoration handling in jgit/egit so that it can check \n>> whether the file is under a pattern that should be excluded. I tried to \n>> implement this but requires using API that eclipse considers internal.\n>>\n>> What do people think? Should I bother with 2 or is it better to \n>> implement decorations for patterns in .git/info/exclude correctly?\n> \n> The decoration should not ignore anything except what the resource filters\n> (affecting visibility) dictates. If a resource is tracked it should be shown unless\n> visibility is prevented by a resource filter or other view specific mechanism.\n> When we track (add) resources recursively we should honor the git ignore\n> patterns, but only for add. Everywhere else we do not just ignore resources\n> that match an ignore pattern.\n> \n> Btw, Here is an attempt to match folders by Team ignore patterns too.\n\nHmmmm, so the proper way is either marking resources as derived and use \nyour patch or implementing .git/info/exclude, correct?\n\n> \n> (OT: I did not format the code. (please try, and you'll see why). We'll have\n> to come up with something better than an 80-column format, it's so seventies)\n> \n> -- robin\n> \n> From 42eadb50b9b87e5324f941ce2d2371e07577f55a Mon Sep 17 00:00:00 2001\n> From: Robin Rosenberg \n> Date: Tue, 17 Jun 2008 22:48:52 +0200\n> Subject: [PATCH] Apply Team/Ignore settings to folders too when tracking new resources\n> \n> We used to only care for file resources. Now folders, and their content,\n> are ignored if the folder name matches a pattern marked as ignored\n> in the Team settings.\n> \n> \n> Signed-off-by: Robin Rosenberg \n> ---\n> .../org/spearce/egit/core/op/TrackOperation.java | 9 ++++++++-\n> 1 files changed, 8 insertions(+), 1 deletions(-)\n> \n> diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> index 6521f1c..af16cdb 100644\n> --- a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> +++ b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java\n> @@ -90,13 +90,20 @@ public class TrackOperation implements IWorkspaceRunnable {\n> \t\t\t\t\t\t\tpublic boolean visit(IResource resource) throws CoreException {\n> \t\t\t\t\t\t\t\ttry {\n> \t\t\t\t\t\t\t\t\tString repoPath = rm.getRepoRelativePath(resource);\n> +\t\t\t\t\t\t\t\t\t// We use add to reset the assume valid bit, so we check the bit\n> +\t\t\t\t\t\t\t\t\t// first. If a resource within a ignored folder is marked\n> +\t\t\t\t\t\t\t\t\t// we ignore it here, i.e. there is no way to unmark it expect\n> +\t\t\t\t\t\t\t\t\t// by explicitly selecting and invoking track on it.\n> \t\t\t\t\t\t\t\t\tif (resource.getType() == IResource.FILE) {\n> \t\t\t\t\t\t\t\t\t\tEntry entry = index.getEntry(repoPath);\n> -\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnored((IFile)resource) || entry != null && entry.isAssumedValid()) {\n> +\t\t\t\t\t\t\t\t\t\tif (!Team.isIgnoredHint(resource) || entry != null && entry.isAssumedValid()) {\n> \t\t\t\t\t\t\t\t\t\t\tentry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath));\n> \t\t\t\t\t\t\t\t\t\t\tentry.setAssumeValid(false);\n> \t\t\t\t\t\t\t\t\t\t}\n> \t\t\t\t\t\t\t\t\t}\n> +\t\t\t\t\t\t\t\t\tif (Team.isIgnoredHint(resource))\n> +\t\t\t\t\t\t\t\t\t\treturn false;\n> +\n> \t\t\t\t\t\t\t\t} catch (IOException e) {\n> \t\t\t\t\t\t\t\t\te.printStackTrace();\n> \t\t\t\t\t\t\t\t\tthrow Activator.error(CoreText.AddOperation_failed, e);\n\n-- \nGalder Zamarreño\nSr. Software Maintenance Engineer\nJBoss, a division of Red Hat\n"},{"id":"80253","messageId":"200806190003.36791.robin.rosenberg.lists@dewire.com","threadId":"14004","inReplyTo":"48592C88.3080302@redhat.com","subject":"Re: [egit-jgit] excluded patterns are decorated as being untracked","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-06-18T22:03:36Z","receivedAt":"2008-06-18T22:03:36Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdagen den 18 juni 2008 17.40.56 skrev Galder Zamarreno:\n> Hmmmm, is marking a resource as \"derived\" recursive? i.e. if I mark \n> \"output\" folder as derived, would anything under it be considered \n> derived? It'd be a pain to go a mark as derived each and every class.\n\nIt seems it is not recursive and worse, not saved with the project.\n\n> I suppose you still need the patch to use Team.isIgnoredHint to get \n> derived resources to be ignored, correct?\n\nYou'll need another patch for the decorator to pick up derived resources\nproperly. Probably not the final solution to decorations. For one thing the\ndecorators are horribly inefficient.\n\n> Hmmmm, so the proper way is either marking resources as derived and use \n> your patch or implementing .git/info/exclude, correct?\n\nI'd say implementing .git/info/exlude is the proper solution. The others are\nmere workarounds.\n\n-- robin\n\n>From 7acc0e63886ed8eda6b38a5edbfe9a6aa4d509dc Mon Sep 17 00:00:00 2001\nFrom: Robin Rosenberg \nDate: Wed, 18 Jun 2008 23:50:42 +0200\nSubject: [PATCH] Decorate derived resources as ignored.\n\nThis is done by using the appropriate API.\n\nSigned-off-by: Robin Rosenberg \n---\n .../internal/decorators/GitResourceDecorator.java | 3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java\nindex 4b6394c..0308f6a 100644\n--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java\n+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java\n@@ -273,8 +273,7 @@ public class GitResourceDecorator extends LabelProvider implements\n \t\t\t\t\t\t\t}\n \n \t\t\t\t\t\t} else {\n-\t\t\t\t\t\t\tif (rsrc.getType() == IResource.FILE\n-\t\t\t\t\t\t\t\t\t&& Team.isIgnored((IFile) rsrc)) {\n+\t\t\t\t\t\t\tif (Team.isIgnoredHint(rsrc)) {\n \t\t\t\t\t\t\t\tdecoration.addSuffix(\"(ignored)\");\n \t\t\t\t\t\t\t} else {\n \t\t\t\t\t\t\t\tdecoration.addPrefix(\">\");\n-- \n1.5.5.1.178.g1f811\n"}]}