goodrobots / MAVCesium

An experimental web based map display for MAVProxy based on Cesium
https://gitter.im/goodrobots/Lobby
GNU General Public License v3.0
41 stars 23 forks source link

app/mavcesium_default.ini should be in .gitignore #28

Closed fnoop closed 7 years ago

fnoop commented 7 years ago

.ini should be .gitignored from commits

SamuelDudley commented 7 years ago

Hopefully this commit solves your issue. Let me know if it doesn't.

fnoop commented 7 years ago

Fresh clone, and then edit of ini file:

[dev] [mav@maverick-ubuntuvm /usr/local/lib/python2.7/dist-packages/MAVProxy/modules/mavproxy_cesium]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   app/mavcesium_default.ini

no changes added to commit (use "git add" and/or "git commit -a")
SamuelDudley commented 7 years ago

Okay, still broken....

SamuelDudley commented 7 years ago

My git foo is weak but because the file is already being tracked .gitignore doesn't work. If I remove the file from being tracked users won't get a copy when they clone the repo. Apparently the correct way to do this (going off the git book) is to put the config in a submodule... At the moment I have the server looking for config files in the user's home directory and the MAVProxy app data directory and prioritising them over the example config. Will it work for you to run a config file external to the repo? Another fix is passing the config parh at runtime as you suggested. Alternatively you can run git update-index --assume-unchanged app/mavcesium_default.ini which should stop tracking the file in your local repo. The problem with this method is that it only works at a local repo level.

fnoop commented 7 years ago

Yes I think you're right - this ini file should be considered a default and not to be altered. If any alterations need to be made, the file should be copied into the home directory or the app data directory, or ideally to a specified location by mavproxy. Can mavproxy really not call a module with a parameter?