From: Galder Zamarreno Date: Wed, 18 Jun 2008 15:40:56 GMT Subject: Re: [egit-jgit] excluded patterns are decorated as being untracked Message-ID: <48592C88.3080302@redhat.com> In-Reply-To: <200806172316.46416.robin.rosenberg.lists@dewire.com> Hi, Firstly, thanks to all for the quick response. Robin Rosenberg wrote: > tisdagen den 17 juni 2008 18.43.12 skrev Galder Zamarreno: >> Hi, >> >> I've been using egit for a few weeks and firstly, I'd like to thank the >> people involved in the project for the work done so far. >> >> There's one thing that has been bugging me about egit though which is >> related to the decoration of untracked files. Egit/JGit does not seem to >> pay attention to .git/info/exclude that I have configured so that >> anything under output folder is excluded. > This is a correct observation. It is a missing feature so far. > >> Egit/JGit does seem to have decorations working fine for patterns >> specified in "Team/Ignored Resources" but it only applies it to files >> not folders, hence, adding "output" as pattern does not work and > I haven't noticed, but looking at the code its seems some we should > use Team.isIgnoredHint instead of what we do now (which only > take a file as an argument). Patch below. The reason I haven't noticed > is that I have only depended on Eclipse marking of resources as "derived" > which worked. (You can mark resources as derived youself in the properties > of that resource, and Egit will ignore it). Hmmmm, is marking a resource as "derived" recursive? i.e. if I mark "output" folder as derived, would anything under it be considered derived? It'd be a pain to go a mark as derived each and every class. I suppose you still need the patch to use Team.isIgnoredHint to get derived resources to be ignored, correct? > >> instead, I have to specify any pattern that would match a file within >> the output folder which is not practical. Folders are taken into account >> as ignored resources in subeclipse (subversion eclipse plugin) >> >> I can see two ways of implementing this that I'm happy to have a look >> into but I wanted to get some advice from the experts of egit/jgit to >> indicate which would be the preferred solution going forward. >> >> 1.- Implement .git/info/exclude functionality in egit/jgit > We need that. Florian came up with a set of patches that should be > usable for this. I haven't applied them to the tree yet. That'd probably be the proper solution to the decoration issue at hand. > >> 2.- Improve the decoration handling in jgit/egit so that it can check >> whether the file is under a pattern that should be excluded. I tried to >> implement this but requires using API that eclipse considers internal. >> >> What do people think? Should I bother with 2 or is it better to >> implement decorations for patterns in .git/info/exclude correctly? > > The decoration should not ignore anything except what the resource filters > (affecting visibility) dictates. If a resource is tracked it should be shown unless > visibility is prevented by a resource filter or other view specific mechanism. > When we track (add) resources recursively we should honor the git ignore > patterns, but only for add. Everywhere else we do not just ignore resources > that match an ignore pattern. > > Btw, Here is an attempt to match folders by Team ignore patterns too. Hmmmm, so the proper way is either marking resources as derived and use your patch or implementing .git/info/exclude, correct? > > (OT: I did not format the code. (please try, and you'll see why). We'll have > to come up with something better than an 80-column format, it's so seventies) > > -- robin > > From 42eadb50b9b87e5324f941ce2d2371e07577f55a Mon Sep 17 00:00:00 2001 > From: Robin Rosenberg > Date: Tue, 17 Jun 2008 22:48:52 +0200 > Subject: [PATCH] Apply Team/Ignore settings to folders too when tracking new resources > > We used to only care for file resources. Now folders, and their content, > are ignored if the folder name matches a pattern marked as ignored > in the Team settings. > > > Signed-off-by: Robin Rosenberg > --- > .../org/spearce/egit/core/op/TrackOperation.java | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > 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 > index 6521f1c..af16cdb 100644 > --- 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 > @@ -90,13 +90,20 @@ public class TrackOperation implements IWorkspaceRunnable { > public boolean visit(IResource resource) throws CoreException { > try { > String repoPath = rm.getRepoRelativePath(resource); > + // We use add to reset the assume valid bit, so we check the bit > + // first. If a resource within a ignored folder is marked > + // we ignore it here, i.e. there is no way to unmark it expect > + // by explicitly selecting and invoking track on it. > if (resource.getType() == IResource.FILE) { > Entry entry = index.getEntry(repoPath); > - if (!Team.isIgnored((IFile)resource) || entry != null && entry.isAssumedValid()) { > + if (!Team.isIgnoredHint(resource) || entry != null && entry.isAssumedValid()) { > entry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath)); > entry.setAssumeValid(false); > } > } > + if (Team.isIgnoredHint(resource)) > + return false; > + > } catch (IOException e) { > e.printStackTrace(); > throw Activator.error(CoreText.AddOperation_failed, e); -- Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat