[FEATURE] Add the ability to "Accept" expired overrides

[OdatNurd]

Summary

Since package expiration is based solely on the time stamps of the related files, it is probably very common that a package updates and many or all overrides that exist for it are expired even though there are no functional changes made.

In order to stop being notified that the override is expired, it is currently necessary for the user to open the override and save it to update the last modification time. For relatively few overrides this can be streamlined by setting diff_unchanged to "open" so that as you manually diff to see, unchanged files open and you can immediately save and close.

For the use case of many overrides it would be handiest to use a bulk diff of the package to see which overrides you need to focus on and then easily mark one or many overrides as being "OK" without having to take extra steps

To that end, there should be something like a context menu item available on overrides that are expired that allows you to "freshen" them without having to open them. Additionally any package that has at least one expired override should offer a context menu to allow you to similarly freshen all overrides in one shot.

Since this could conceivably mask problems, I'm envisioning that this would prompt you to verify that you meant to do it the same way that deletion does. This would probably be configurable in the same way and possibly allow you to specify that you only want to confirm on a "bulk freshen" but not on an individual one.

Questions

How objectionable would it be if, when doing a "Bulk Freshen" every override was touched instead of just those that are currently expired?

Clearly that is a lot easier to implement as a context item on the package because the list of all overrides is easier to come by than those that are expired once the report is finished generating.

My current thoughts are that this could be considered to be a benefit in that it would mean that all overrides for a package were all "reviewed" (for lack of a better term) at the same time.

I think this is really only an issue for packages installed via PackageControl, because it seems like when PackageControl updates a package it creates an entirely new sublime-package file, in which case the entire contents of the package would always have the current date and so every override would be expired all at once.

By contrast the packages that ship with sublime (at least in Linux 3126) contain files with different time stamps.

[keith-hall]

Hmm, it's a shame that Package Control creates an entirely new sublime-package file on package upgrade whereby all the files it contains have the current date and time, because having to freshen overrides that seem to be expired despite the fact that the base files haven't changed means one would lose the modified-date-time of the override as an indicator of when they made the override/change, which could be useful for remembering why they made it or finding something else they did around the same time.

I guess as there is nothing we can really do about that, we just need to be aware of it and be sure to include the original date as a comment in the override file when making changes, for example. :)

[keith-hall]

Further investigation reveals that Package Control downloads a zip from the GitHub repo, and inside that zip file, all files have their modified date set to the date/time of the most recent commit. Based on this knowledge, I'd be perfectly fine with OA touching every override instead of just those that are genuinely expired - the chances are that all simple overrides will be detected as expired anyway.

[OdatNurd]

I suspected it was doing something similar to that but I hadn't found the time to really dig through the code to see the full mechanics of it. Thanks for looking into that!