A large series of changes to a group of jobs was implemented in part by editing the job config.xml files directly followed by a "Reload Configuration From Disk" in the Manage Jenkins area.

I suspected this might be 'confusing' to the Job Config History plugin, so I went to the job's Configure page (intending to save the configuration without changes to create a new history entry) - but the configuration was clearly the old configuration prior to edits.

It would be nice if there was a way to clue the Job Config History plugin that the config.xml has changed outside of the job's Configuration page.  From a user's perspective (I have no idea how Jenkins is implemented) there are a couple of ways this could happen:

1) The job config history could fire something off when "Reload from disk" occurs to compare job configs and update (create a new history entry for) any changed job configs, assigning the new version to the user executing the reload.

2) There could be a button/link on the job page that basically says "Create a new job config from whatever is on disk" - effectively a "single job reload configuration" that creates a new history entry.

3) When the Configuration link is pressed, somehow Jenkins seems to know to take the "old" history and not the one currently on disk.  It could put up some kind of warning dialog and allow users to choose whether to start from the current on-disk configuration or the last-saved configuration.

I could find no documentation that cautioned about Job Config History's not being able to handle "Reload".  (I hope I didn't miss it!)  I recognize this is not the typical use case but I clearly Jenkins understands some users manipulate raw config XML (or it wouldn't provide the Reload button!).  Therefore the Job Config History plugin ought to address this case - even if initially it is to simply document that this use case is not currently supported.

This is all cool stuff.  I'm not trying to say something's bad, just suggesting that something could be improved.