Based on my ad-hoc tests it would appear that the scm-sync plugin has hooks within the Jenkins web UI / API which cause changes to be pushed to the scm repository. This works for simple changes like modifications to jobs made through the Jenkins dashboard, however this hooking mechanism is fragile at best due to the plethora of ways configuration files can be changed.

The most notable use case I've discovered is that any changes made directly on the file system on the Jenkins master do not get reflected in the repository used by the scm-sync plugin. So, for example, if one opens up a config.xml file on the server using a text editor and makes modifications to the file, saves it and triggers a 'reload from disk' on the Jenkins dashboard, those changes never get propagated to the scm repo. Further, if later someone does a "reload" of the scm-sync plugin to pull changes back down from the repo, these local modifications get lost.

While this is the easiest use case I've discovered in my limited testing, I've also discovered several other ways this same behavior can be reproduced. For example, certain plugins store their configuration information in support files external to the main config.xml (ie: console log parser and scriptler are but two). So even when one modifies these settings via the Jenkins dashboard, the changes don't get reflected in the scm-sync repository (presumably because the hooks necessary for that plugin to pick up the changes are not in place).

Overall it would seem to me to be a much more robust implementation if the scm-sync plugin could be configured to detect changes made on the file system regardless of the sources of the change. Then use cases like the ones I just described would no longer cause issue. Also, this would allow the scm-sync plugin to scale nicely as new plugins and edit sources are used by a Jenkins configuration.