tisdag 11 december 2007 skrev Wink Saville: > Shawn O. Pearce wrote: > > Wink Saville <wink@xxxxxxxxxxx> wrote: > > > >> I'm trying to use git on an Eclipse workspace and the .metadata > >> directory is chock full of files and was wondering what, if anything, > >> should be ignored. At the moment .history looks like a candidate for > >> ignoring there are probably others. > >> > > > > Ignore all of .metadata; its Eclipse private state that you don't > > want to version. I'd add it to .git/info/exclude so its ignored only > > in the repository that is using Eclipse, rather than in .gitignore > > (which is published). > > > > > Shawn, > > I added .metadata to exclude then used git rm to remove > .metadata from the repository. I then cloned that > repository to see how Eclipse would work. (As part of my > workflow I use git as a backup so I wanted to see what would > happen when I "restored".) > > As I'm sure you know with the metadata gone my existing projects > in the Ui were gone and they have to be recreated as well as > some Eclipse and plugin specific configuration. > I understand you and others are working on an Eclipse plugin > for git, will it also ignore . metadata? I don't put my projects into the workspace directory so I don't have that problem. I think mixing projects and workspaces is a bad idea (from experience, especially when testing different Eclipse versions on the same projects. As for settings you can configure project specific settings, rather than workspace settings for most interesting settings. You can also export/import settings. Getting projects into a new workspace is best done using import. Point import to a directory and it will scan for all projects and let you import them all in one go. Egit doesn't ignore .metadata by default, I think. Probably should. For now you can tell egit to ignore it via the workspace settings, which egit honors. Eventually it will honor .git/info/exclude etc, but currently it doesn't. > > Do you need any testing done or is it too early? I'd be glad to > test if you feel its solid enough that I won't lose data or if it > uses a separate different repo then I could use both. Sure testing is needed. It's solid enough to be usable, but probably not bug free and isn't feature complete. So if we can root out some bugs and not just introduce new buggy features that helps. Not that development is very fast nowadays, but having real users spurs development and hopefully gets more contributors. The likelyhood of loosing data is probably very low as few operations are dangerous. Of course, there is no warranty etc. etc. and we haven't done very much monkey testing (unless using the plugin on windows counts). I use egit and git on the same work dir in parallel, sometimes using egit, sometimes git-gui and sometimes plain git depending on which does the work better. -- 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
