Re: [cdt-dev] .settings/language.settings.xml meant to be revision controlled?
Yes, I agree it is a bug to have it as part of the project. It's
underlying usage is still important, so storing it in the workspace
makes sense to me.
Perhaps Andrew Gvozdev can comment further.
In the meantime the env-hash was introduced in the fix for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=382423, although AFAICT
it is actually not 100% related and actually added at the same time,
not because the Cygwin specs provider required it anymore than
previous ones. Since then the idea has been expanded to hash other
parts of the environment, such as the path and modification date of
the compiler and a few other things (see
AbstractBuiltinSpecsDetector.calculateEnvHash()) for details.
Kichwa Coders Ltd.
On 7 January 2017 at 12:14, Elmenthaler, Jens
> Hi all,
> I wonder if there is some guidance whether to put
> .settings/language.settings.xml under revision control or not.
> Looking at the contents, I see indicators to put it under revision control,
> since all developers should share the same settings, and not re-enter them
> every time the project is imported, e.g.:
> - The list of all enabled language settings providers that the
> project requires is stored there.
> - Adding user settings and enabling “Store entries in project
> settings” stores my user setting there.
> On the other hand, there is the GCCBuiltinSpecsDetector with the env-hash
> attribute, whose value depends on the user’s environment. Its value depends
> on the value of the user’s PATH environment variable, and thus sharing is
> not possible.
> I tend to treat everything in the .settings folder to be put under revision
> control. In this case, however, storing the env-hash attribute in
> .settings/language.settings.xml as opposed to
> seems to be a bug.
> Any opinions?
> Greetings, Jens.
> cdt-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit