> Importantly, engineers should be on-call for their code - being on-call creates a positive feedback loop and makes it easier to know if their efforts in writing production-ready code are paying off. I’ve heard people complain about the prospect of being on-call, so I’ll just ask this: if you’re not on-call for your code, who is?

OK, that's fine, but in that case we can shut down the production system outside of business hours so that our work-life balance isn't affected. Oh? We can't shut down the production system outside of business hours? So we need to be on call continuously, 24/7, meaning we can't ever be off the grid or unavailable? That sounds like a we're expected to give up our personal lives at a moment's notice? Interesting, hmm.

This is a great looking tool.

What I have been doing by hand for some time is putting code for different customers in different directories and having a conditional in `~/.gitconfig` to determine what config applies there:

    [includeIf "gitdir:~/projects-private/**"]
      path = ./.gitconfig-private

    [includeIf "gitdir:~/projects-client/**"]
      path = ./.gitconfig-work

Then in .gitconfig-private or .gitconfig-work I have all the usual gitconfig settings that apply, for example the [user] section...

Switching to the right directory thus automatically changes the settings.