Community
Participate
Working Groups
1.1.0.201109151100-r EGit considers derived resources as if they were mentioned in .gitignore. This looks like a nice Eclipse integration on first sight, but it causes trouble when git is used on the command line (since derived resources are not ignored there). The special handling for derived resources must be removed. The only help EGit could offer is to ask if it should add derived resources to the .gitignore when a project is added to a repository. Looks like bug 341502 introduced this bug.
This is highly confusing. I was working on a .gitignore file, and I really couldn't explain why an untracked xxx.log file didn't get a decoration (i.e. looked like ignored). It turned out that this is because GitLightweightDecorator#decorate(..) calls Team.isIgnoredHint(resource). That method excludes derived resources and those whose name matches a pattern from Preferences > Team > Ignored Resources. Neither the derived bit nor the "Ignored Resources" list should be silently applied in EGit. As a first step, EGit should stop calling Team#isIgnoredHint(..). As a later enhancement, you could use that method to automatically add untracked files to .gitignore. This is not only about decorators. E.g. "Team > Add to Index" also doesn't work for such files, but adding them in the Git Staging view works fine.
Please add a workspace preference setting whether derived sources should be ignored or not. In our project we like the derived sources to be checked in and versioned as well. It is inconvenient to always having to use the git console to add a derived source, because EGit is not capable of that.
I second this request.
> Please add a workspace preference setting whether derived sources should be > ignored or not. I don't think a preference is necessary. To fix this bug, EGit should just stop calling Team#isIgnoredHint(..).
Jens, could you please have a look at this? The change to use Team.isIgnoredHint in GitLightweightDecorator was done in this commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=74510d09b9c5b18f4f7e273941d305d7f1ced95e And the change in ContainerTreeIterator: http://git.eclipse.org/c/egit/egit.git/commit/?id=df27ebc65d7eb50b3c8eae96155e58c865241b7e
pushed fix for review https://git.eclipse.org/r/#/c/7681
Merged: http://git.eclipse.org/c/egit/egit.git/commit/?id=4a87652bde4f88327288a9cc02f3f4951fdf3aab
I don't think you should have done this without also fixing 297674.
I'm confused. Forever Eclipse CVS ignored resources in ".cvsignore" file as well as derived resources (eg. "bin" folders) even though any CVS command line client didn't know about derived resources. This rule has been followed in many other team integrations (eg. SVN and ClearCase). The concept of "derived resources" is from Eclipse applied independent from the actual team provider's own concepts (such as .gitignore or .cvsignore). For example, the JDT compiler calls #setDerived to mark generated class files. So why is this confusing for Git?
> So why is this confusing for Git? It was wrong from the beginning, and it sounds like other team providers just copied the wrong behavior of the Eclipse CVS client. With the Eclipse CVS client, it was not even possible to use a command line CVS client to perform operations on an Eclipse project (because "extssh" was not a standard protocol). And AFAIK, nobody really wanted to use CVS from the command line. In contrast, the EGit UI doesn't give you all the functionality of command line Git, so there's a much higher chance that people use both the command line and EGit.
(In reply to comment #10) > It was wrong from the beginning, and it sounds like other team providers > just copied the wrong behavior of the Eclipse CVS client. Sounds valid. Is this written down somewhere? Shouldn't this be documented in the Team APIs (eg., via @deprecated)?
I think the "Hint" in org.eclipse.team.core.Team#isIgnoredHint(IResource) already tells that this is not a definitive answer. You could file a bug for Team to mention that this should not be silently applied, but that is should serve as a starting point for the team-provider specific ignore mechanism. In EGit, that would be bug 297674.
(In reply to comment #5) > Jens, could you please have a look at this? > > The change to use Team.isIgnoredHint in GitLightweightDecorator was done in > this commit: > > http://git.eclipse.org/c/egit/egit.git/commit/ > ?id=74510d09b9c5b18f4f7e273941d305d7f1ced95e > > And the change in ContainerTreeIterator: > > http://git.eclipse.org/c/egit/egit.git/commit/ > ?id=df27ebc65d7eb50b3c8eae96155e58c865241b7e We introduced the ignore handling due to some user demand but I think it is the better solution not to consider Team ignore hints to be consistent with the command line.
EGit used Team.isIgnoredHint from the very first incarnation, long before there was .gitignore support.
