From: "Tor Arne Vestbø" <torarnv@gmail.com>
To: Ferry Huberts <ferry.huberts@pelagic.nl>
Cc: git@vger.kernel.org, Robin Rosenberg <robin.rosenberg@dewire.com>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [EGIT] [PATCH v1 1/1] Add an ignored icon
Date: Tue, 24 Feb 2009 00:59:30 +0100 [thread overview]
Message-ID: <49A33862.90507@gmail.com> (raw)
In-Reply-To: <ec97c536d418f465befba2a7f30f82f0d75004f8.1235415747.git.ferry.huberts@pelagic.nl>
Ferry Huberts wrote:
> Add an ignored icon to the label decorations page and make
> sure that it is actually decorated: from now on do not ignore
> ignored resources during decoration.
The reason this was not added in the original series was because that's
kind of the point of ignoring a resource -- you don't want any
information about it. Also, none of the other team plugins provide
decorations for ignored resources-
On the other hand, since the decorators are now user configurable,
adding the option to allow users to enable decoration of ignored
resources if they really feel it's useful to them is admittedly in line
with the whole customization idea.
Though I'm not sure if this particular case of customization would cause
more confusion than good, for example in terms of which doors we open by
allowing ignored resources to actually not be ignored (i.e what other
features would you expect to work for ignored resources?).
> prefs.setDefault(UIPreferences.DECORATOR_SHOW_UNTRACKED_ICON, true);
> + prefs.setDefault(UIPreferences.DECORATOR_SHOW_IGNORED_ICON, true);
> prefs.setDefault(UIPreferences.DECORATOR_SHOW_STAGED_ICON, true);
If applied, I would argue that the option should be _off_ by default, to
match the behavior of the other team plugins and the normal logical
action of ignoring a resource.
> + /** Decoration for resource ignored by Git */
> + public static final ImageDescriptor OVR_IGNORED;
> +
Side-note: the current decoration implementation only uses Eclipse's
concept of an ignored resource -- not .gitignore et al. since we don't
have a standard way of reading those yet.
Tor Arne
next prev parent reply other threads:[~2009-02-24 0:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 19:03 [EGIT] [PATCH v1 0/1] Add an ignored icon Ferry Huberts
2009-02-23 19:03 ` [EGIT] [PATCH v1 1/1] " Ferry Huberts
2009-02-23 23:59 ` Tor Arne Vestbø [this message]
2009-02-24 5:15 ` Ferry Huberts (Pelagic)
2009-02-24 6:11 ` Ferry Huberts (Pelagic)
2009-02-24 9:23 ` Tor Arne Vestbø
2009-02-24 9:22 ` Ferry Huberts (Pelagic)
2009-02-24 7:06 ` Robin Rosenberg
2009-02-24 9:28 ` Tor Arne Vestbø
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=49A33862.90507@gmail.com \
--to=torarnv@gmail.com \
--cc=ferry.huberts@pelagic.nl \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@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).