Re: [egit-jgit] excluded patterns are decorated as being untracked

> 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).

> 
>> 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.

> 
>> 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.

> 
> (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 <robin.rosenberg@dewire.com>
> 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 <robin.rosenberg@dewire.com>
> ---
>  .../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);