When people talk about making a single global change to update all clients when they change an interface, are they updating unsubmitted changelists too?
Unsubmitted changes at Google usually come in one of two flavors, short-lived (abandoned or submitted within a few days) or perpetual. The latter flavor is often for "I think we might want this". It's not uncommon for those to be completely rewritten if they're actually needed. There's usually a preference for submitting useful things (with tests!) and flag gating them to cut down on bitrot.
I have seen exceptions -- I reported a bug in a fiddly bit of epoll-related code and an engineer on my team had a multi-year-old fix -- he hadn't submitted it because he wasn't confident he'd found an actual bug. The final changelist number was more than double the original CL number (unsubmitted changes get re-numbered to fit in sequence when they're submitted -- the original number redirects to the final submitted version in our tooling).
Well, the act of submitting a changelist essentially runs a test suite which requires that the changelist has no merge conflicts with the head and that the relevant tests pass. From that it follows that if someone changes an interface, you'll get either merge conflicts or test failures on your own changelist. Meaning - it's the changelists authors task to sync it up to the current head state so the refactorers won't touch unsubmitted changelists.
It's pretty much the same as GitHub pull requests - the changelists are supposed to be decently short lived and if the master code changes it's up to you to resolve conflicts and get it into a mergeable state again.
