lördag 26 september 2009 22:10:16 skrev Mark Struberg <struberg@xxxxxxxx>: > > As you already pointed to: we have to clearly separate between settings stored in the project itself and settings stored in the workspace. The first are by far not all settings needed, the 2nd are not checked in to git anyway. Maybe I didn't find it yet, but is there an ability to set formatter settings for XML (e.g. Tabs vs spaces policy)? I was only able to specify this for the whole workspace and not on a per project basis. Those are workspace settings in the 3.4, not checked 3.,5 yet. You could add it to bugzilla as a feature request. All settings should be available as project settings I think. > And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this For JGit, not really. Everything that is not project settings should be left as the default. The only reason is tool constraints. I'm not well versed enough to tell what neatbeans does here. > feature for a lot non-Eclipse users too (e.g. for Jonas who hacks the nbgit NetBeans plugin based on JGit (again: EGit is a different story!)). I'm not sure keeping netbeans settings would be a problem, but that is about how much we could do > > > > > We use 3.3 (well I think the last user dropped it > > recently), 3.4 and 3.5. I often have to fix up new projects > > but that is typically a one-time per eclipse project > > problem. (typically the JRE gets bound to a specific install > > location). > > > > The .launch files is another story since they change format > > all the time. > > And the profiler settings, and and and. It's sad, but the list is long :( Yep... > We can also let the eclipse settings files checked in currently if you like. But I'd be happy if we continue collecting information and then make a decision. I definitely think we should keep them until we find an alternate solution. The projects settings are way too useful to be thrown out. -- robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html