From: Galder Zamarreno <galder.zamarreno@redhat.com>
To: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
Florian Koeberle <florianskarten@web.de>,
Marek Zawirski <marek.zawirski@gmail.com>
Subject: Re: [egit-jgit] excluded patterns are decorated as being untracked
Date: Wed, 18 Jun 2008 17:40:56 +0200 [thread overview]
Message-ID: <48592C88.3080302@redhat.com> (raw)
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 <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);
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
next prev parent reply other threads:[~2008-06-18 15:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 16:43 [egit-jgit] excluded patterns are decorated as being untracked Galder Zamarreno
2008-06-17 21:16 ` Robin Rosenberg
2008-06-18 4:39 ` Shawn O. Pearce
2008-06-18 15:40 ` Galder Zamarreno [this message]
2008-06-18 22:03 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48592C88.3080302@redhat.com \
--to=galder.zamarreno@redhat.com \
--cc=florianskarten@web.de \
--cc=git@vger.kernel.org \
--cc=marek.zawirski@gmail.com \
--cc=robin.rosenberg.lists@dewire.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).