But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.
no more than claiming that we are legally required to upstream the patch.
the argument is though that repatching is work, and especially it's the kind of work you do not want to be stuck with while you upgrade, because if you forget to do it ahead of time, which is likely to happen, you end up with a potentially large downtime or an unexpected delay in the upgrade process.
in other words: the actual truth is: we can't upgrade unless we reapplied the patch to the new version. basically, it is about making the re-patch process appear as dramatic and disruptive as possible.
the leaders can't deny the possibility, because the code that is patched could change dramatically, to the point that you have to redo all the work from scratch.
i am actually stuck in such a situation with one of my projects. i need to merge two branches that were created some time ago causing a divergence that would have been easy to deal with, had i properly merged the branches at the time. now the merge will take as much effort as the original development.
as developers we all know this of course. the challenge is to explain this to the leadership in ways that they can understand.
But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.
Again, that's my experience.