On August 18, 2022 2:18 PM, Junio C Hamano wrote: >To: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> >Cc: Sergio via GitGitGadget <gitgitgadget@xxxxxxxxx>; git@xxxxxxxxxxxxxxx; >Sergei Krivonos <sergeikrivonos@xxxxxxxxx> >Subject: Re: [PATCH 2/2] Add Eclipse project settings files to .gitignore > >"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> location). For example, I do this with Vim-related files, and it >> applies to all repos on my system, such that other developers don't >> have to care what editor I use. >> >> However, Eclipse is a popular editor, so it may be that Junio really >> likes this change since it will benefit many people. > >I am all for making new contributor's life better, and in this case, NOT adding >editor-specific patterns to OUR .gitignore contributes better for that goal. It will >be a shame for us to make a move that will keep our contributors unaware of >what they can do with Git, and in this case, lack of Eclipse specific patterns did >trigger Sergio to notice that these are not ignored, and learn that a better place to >do so is in $HOME/.gitignore, because it will help not only when the contributor >works on Git, but when the same contributor works on anything using Eclipse. >Adding editor-specific patterns ourselves robs such a learning opportunity from >new contributors. There is a related case to this in ECLIPSE, https://bugs.eclipse.org/bugs/show_bug.cgi?id=575408, discussing a problem with where ECLIPSE CDT is improperly storing and modifying build settings. What my project team found is that much of the ECLIPSE settings need to be preserved, especially the encodings - .gitignore is not a valid option for these. ECLIPSE has a habit of inheriting container encodings, which is not always correct (we keep our files in UTF-8 not cp1292). Most settings should be retained, but the ones in .settings/language.settings.xml changes each time ECLIPSE restarts or sometimes clones a project. Unfortunately, some of the settings in that file are needed to bootstrap builds for new clones. The case has been open a while with no resolution. Whether a good idea or not, what our team found an acceptable solution is to use update-index --assume-unchanged on that specific file and manage other ECLIPSE artifacts in git not excluding them in .gitignore. --Randall
