How about building a separate branch for doge specific codes?
Any new changes specific to doge should be merged to this separate branch first. You will only merge these changes to master when you want new client version release, while you may add a tag to make it clear on master these changes are doge-specific and the rest are not.
So even if the next Bitcoin v0.12 may contain 2000+ new commits, you won't easily lose moviation to rebuild doge client again.
Yup, we've done more or less that; there's two branches, 1.10-dev which is everything needed to get network consensus (i.e. it will sync) and a separate 1.10-branding which is everything needed to make it look like Dogecoin (a much bigger, but easier to reproduce change set). We've also restructured our code heavily to make it less invasive to the Bitcoin code, so incoming changes are less likely to be an issue.
I imagine for v0.12 we'll probably rebase these branches to layer our patches on, rather than trying to apply the Bitcoin patches, but generally that's the model we're using. It's been quite positive clearing out all the old cruft and starting new, so I suspect we'll rebuild every few releases anyway (anything generic we push into Bitcoin anyway, so we should never diverge too much).