Add "enable git integration" option to settings

[mmzmusicnotes]

• Add a checkbox to the settings dialog that enables or disables the git integration
• When this checkbox is enabled, import and export (merge build and export source) will use git to perform their operations, as described in the relevant issues
• When the checkbox is disabled, they will not
• This issue covers the UI, and adding a way to read the setting and determine whether the feature is enabled

[joyfullservice]

I think I have this pretty well in place, as of 4d734da. We can adjust these options as we go forward in the development phase, but we will want them pretty well established before merging this branch into master.

[mmzmusicnotes]

Overall, this looks exactly as I was imagining! Just wondering if you could elaborate on what the "deep inspection" settings do? Also, some of these boxes seem to duplicate settings available elsewhere, unless I am misunderstanding them?

[joyfullservice]

The "Deep Inspection" concept is for items that don't store a modified date in Access, and it can be more difficult to accurately determine whether the object has changed since the last export/import. With shared images, for example, if you replaced an existing image with a different one but with the same name, (such as a corrected image) you would not see any difference in the metadata items like the name and original file name. It would require a hash of the image file itself, which would be a more expensive operation in terms of performance, and would technically have to be done each time you wanted to check for changes in the database components.

The idea here is that in most real-life use cases, you are not actually changing this kind of data, so you could skip these slower comparisons. For those (unusual) edge cases, you could simply check the box to include those checks. For a small database it really wouldn't make much difference, but for a very large one with hundreds or thousands of shared images, it could be a significant difference.

[mmzmusicnotes]

Ah, that makes sense. Here is one more case where we may want to use "Deep inspection":

There is a bug in Access where forms do not respond to changes to a form's RowSource when that RowSource has inline SQL. We've run into this using my old version of the plugin several times, and it can be frustrating - it looks like Access is ignoring your changes despite them being in code.

Here are some other people reporting this or similar issues:

• https://answers.microsoft.com/en-us/msoffice/forum/all/access-2010-changes-to-rowsource-property-for/31f9950f-cd4d-47a8-a960-86bc24329c54
• https://answers.microsoft.com/en-us/msoffice/forum/msoffice_access-mso_win10-msoversion_other/query-in-report-wont-save/029740a6-7cb8-41d5-a4a1-f398d2e8faee?page=2
• https://www.devhut.net/2018/03/13/ms-access-bug-record-source-and-row-source-changes-not-saving/
• https://stackoverflow.com/questions/17453990/access-combobox-not-changing-when-rowsource-is-changed

Our current workaround is to either rebuild the whole DB from scratch (doing a regular "merge build" in the plugin now), or to change inline SQL into a query, and run the query instead.

We could make a separate issue for this, but it might be wise to have a "deep inspection" option for forms and modules, as well, given this problem.

[joyfullservice]

The option has been added, but recently hidden because it was creating confusion for new users.