headers
Authorization header
Plain old HTTP Basic auth can be handled elegantly using the onAuth handler.
But if you want to use Bearer auth or something, any value you manually set for the Authorization header will override the derived value.
User-Agent header
Regretably, some git hosting services have User-Agent specific behavior.
For instance, GitHub will correctly interpret git HTTP requests made to a repository URL that is missing the .git suffix but ONLY if the User-Agent starts with git/.
And in fact, does not interpret git HTTP requests for gists correctly at all unless the User-Agent start with git/ (bug #259).
Since 2015 the specs state that setting a custom User-Agent header in fetch should override the default. This works in Firefox (bug #247), but Chrome has a bug so setting a custom User-Agent doesn't work at all (chrome bug #571722).
The @isomorphic-git/cors-proxy solves some of this problem by checking if the User-Agent starts with git/ and if it doesn't, it sets the User-Agent to git/@isomorphic-git/cors-proxy. So cloning gists using a proxy works.
CORS also has a strange relationship with the User-Agent header. Setting a custom User-Agent header requires that 'User-Agent' be explicitly whitelisted in the CORS pre-flight request (bug #555).
As you can see, User-Agent is basically a mine field. Which is why as of version 1.0 this library doesn't touch it. There is no solution that works for everything (GitHub handling URLs without .git, cloning gists, setting it in Chrome, setting it in a proxy, CORS). This is your problem now, not mine. Go bug GitHub, Inc to stop using user-agent filtering.
X- headers
There is nothing stopping you from setting custom headers if you really want. But if you're doing it in a browser you'll either need to run the CORS proxy on the same domain or run a custom CORS proxy to whitelist those headers if they aren't already whitelisted.