git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tor Arne Vestbø" <torarnv@gmail.com>
To: "Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl>
Cc: Jon Smirl <jonsmirl@gmail.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: jgit and ignore
Date: Sun, 01 Mar 2009 15:58:59 +0100	[thread overview]
Message-ID: <49AAA2B3.40808@gmail.com> (raw)
In-Reply-To: <49AA91F0.7050008@pelagic.nl>

Ferry Huberts (Pelagic) wrote:
> Tor Arne Vestbø wrote:
>> In my opinion, EGit should default to using Eclipse's built in ignores,
>> but then detect the presence of a global core.excludesfile, in which
>> case it would notify the user ("I see you have a core.excludesfile") and
>> let the user switch to using that one instead.

[snip]

First of all, I do appreciate you working on the ignore feature :)

> I do not agree with your propasal however.
> We then would have different behaviour between how 'git' behaves within
> Eclipse (by means of the plugin) and how 'git' behaves within the
> command line. That alone can cause much more confusion.

I see what you mean, and I agree that in general the command line git
porcelain and the Eclipse git porcelain should work in similar ways.

But, with that said, I think of EGit as a standalone Eclipse-plugin
implementation of the git porcelain -- not just a wrapper around the
command line porcelain.

To me that means that EGit should focus just as much on integrating with
Eclipse properly as it does on keeping command line porcelain
interoperability.

The core.excludesfile is one such case, and I think my proposal is a
good compromise.

> Your proposal can also be implemented differently by (for example)
> building a UI that allows the user to edit the global ignore file.

That would be going out of scope of Eclipse as a framework, and also
does not solve the problem for those users who have a list of global
team ignores, and expect the Git plugin to just work with those ignores.

> The Eclipse global team ignores simply are too broad: think of the
> situation where I also have non-git project (like svn) in my workspace.

Not sure I understand? Isn't that exactly why you would have Eclipse's
global ignores specified in one place -- so that they could be shared
between version control systems instead of replicated in each repo?

Let' say you have a CVS project, a SVN project, and a Git project in
your workspace. The CVS and SVN projects would pick up ".bak" as an
ignore pattern from your team ignores, but the Git project would not.

To make the Git project pick it up, you would have to either add it
(repatedly for more than one project) to the .gitignore of that project,
or open an editor outside of Eclipse to edit your ~/.gitconfig.

Either ways seem redundant and awkward to me.

Tor Arne

  reply	other threads:[~2009-03-01 15:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-28 16:31 jgit and ignore Jon Smirl
2009-02-28 17:26 ` Shawn O. Pearce
2009-03-01 10:11   ` Ferry Huberts (Pelagic)
2009-03-01 12:54     ` Jon Smirl
2009-03-01 13:06       ` Ferry Huberts (Pelagic)
2009-03-01 13:34         ` Tor Arne Vestbø
2009-03-01 13:47           ` Ferry Huberts (Pelagic)
2009-03-01 14:58             ` Tor Arne Vestbø [this message]
2009-03-01 17:16               ` Shawn O. Pearce
2009-03-01 17:42                 ` Tor Arne Vestbø
2009-03-01 17:49                   ` Shawn O. Pearce
2009-03-01 17:51                     ` Tor Arne Vestbø
2009-03-01 17:57                       ` Shawn O. Pearce
2009-03-01 17:43                 ` Ferry Huberts (Pelagic)
2009-03-01 17:47                   ` Shawn O. Pearce
2009-03-01 20:24                 ` Robin Rosenberg
2009-03-04 17:50                   ` Ferry Huberts (Pelagic)
2009-03-01 17:17               ` Ferry Huberts (Pelagic)
2009-03-01 14:08         ` Jon Smirl
2009-03-01 14:21           ` Tor Arne Vestbø
2009-03-01 14:31             ` Jon Smirl
2009-03-01 14:33               ` Tor Arne Vestbø
2009-03-01 20:47               ` 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=49AAA2B3.40808@gmail.com \
    --to=torarnv@gmail.com \
    --cc=ferry.huberts@pelagic.nl \
    --cc=git@vger.kernel.org \
    --cc=jonsmirl@gmail.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).