| Keeping language.settings.xml under source control? [message #1720759] |
Wed, 20 January 2016 11:59  |
Eclipse User |
|
|
|
I'm trying to set up CDT to drive existing cross-compile builds with makefiles using the build output parser and the cross-gcc compiler built-in setting detector. I'm mostly successful but I'd like to keep .settings/language.settings.xml under source control so that anyone who checks out our project will get all provider settings automatically. One minor annoyance is that CDT keeps updating the env-hash attribute of each configuration's <provider class="org.eclipse.cdt.internal.build.crossgcc.CrossGCCBuiltinSpecsDetector" element after the project is checked out into the local workspace resulting in a spurious local change to language.settings.xml that may be confusing to other developers and lead to unnecessary commits. Is it a bad idea to keep language.settings.xml under source control and if not is there anything that can be done to prevent updates to language.settings.xml unless project configuration has actually changed?
[Updated on: Wed, 20 January 2016 12:14] by Moderator |
|
|
|
|
|
|
|
|
|
| Re: Keeping language.settings.xml under source control? [message #1847992 is a reply to message #1783652] |
Tue, 16 November 2021 09:01  |
| Eclipse User |
|
|
|
I realise it's been a while since the last post, but I thought my experience would be of interest.
Basically, we started off storing the language.settings.xml files in source control (git) and it was pretty annoying that they showed up as changes every time people wanted to commit, when the only changes were on the env-hash field. We (I) experimented with removing them from git and found that everything works quite normally when they are re-created.
However, I've recently found an issue with one project whereby the indexer messes up in [at least] one project. When I remove the "CDT Managed Build Settings Entries" from the list of "Preprocessor Include Paths, Macros etc." and, instead, set exactly the same items in the "CDT User Setting Entries" provider (such that, when I look at the list of "Includes" in Project Explorer, it is exactly the same list as before!), the indexer works better, although still not great (at least symbols within the same source file get indexed properly!).
In the "Providers" tab, when I check the "Store entries in project settings folder (easing project migration)", the include paths I've configured go into language.settings.xml so, unless I can find another way of 'fixing' the indexing in this case, it may be that I need to share that file through git.
The gist of this, therefore, is that, if you stick with the default settings, there's no need to share language.settings.xml but, if you change anything that affects language.settings.xml (other than the env-hash field), then sharing it via source control appears to be necessary.
Therefore it seems to me that, as other people have suggested, there appears to be some conflict in the use of language.settings.xml; I suspect (as someone else mentioned, I think) that the env-hash stuff should be removed and be stored somewhere in the workspace, not the project folder.
[Updated on: Tue, 16 November 2021 09:55] by Moderator |
|
|
| Re: Keeping language.settings.xml under source control? [message #1854056 is a reply to message #1847992] |
Fri, 29 July 2022 13:17 |
| Eclipse User |
|
|
|
Sorry, I realize that this is a very old post, but this is one of the top results on google for "git eclipse env hash", and I have another solution.
my solution is to have git replace the env-hash value with 0s leaving the rest of the file intact. that way changes to the hash will be ignored but anything else in the file that changes will be committed.
1. add a .gitattributes file to your repository containing
.settings/language.settings.xml filter=eclipse_env_hash
2. add the following to .git/config
[filter "eclipse_env_hash"]
clean = sed 's/env-hash=\"[-,0-9]*\"/env-hash=\"-000000000000000000\"/g'
smudge = cat
|
|
|
Powered by
FUDForum. Page generated in 0.08857 seconds
Home