git(1) uses one representation when storing source code (not binary) by default which IIRC is utf-8 (no working-tree-encoding). Is this the same default as in Go?
I tried comparing to Git but have problems finding a more authoritative specification document in regard to limitations of all kinds (e.g. Unicode versions, code ranges, normalization form requirements).
When we compare with "How default is the default encoding (UTF-8) in the XML Declaration?", I'm under the assumption that loading go source from git is fine, but only if it was stored into git as go source files.
By default Git does not have any single "source code representation" and stores files exactly as they were added, with no change in text encoding.
Git at its core doesn't even have the concept of "source code"; it only deals with "blobs" i.e. binary objects. Unlike the Go compiler, Git has no inherent need to understand what it is storing.
In part this is because Git commits are snapshot-based, not delta-based (they are not stored as text diffs), which removes the need to treat text files differently from binary files.
Git has a slight preference for UTF-8 – most "high-level" subcommands that specifically work with text data (e.g. git diff) will generally expect UTF-8, or at least some ASCII-based encoding (unless told otherwise through .gitattributes; e.g. an UTF-16 file is non-ASCII so it would be recognized as binary data in diffs if its encoding was not manually specified).
(Most such tools still don't care about any specific Unicode version; it is enough for them that they can decode bytes into runes (codepoints).)
But the "generic" subcommands like git add or git checkout handle all files as if they were binary data by default, without enforcing any encoding or converting the files.
Though the 'gitattributes' file (man gitattributes) can be used to either have Git convert the file into UTF-8 when it is added (the working-tree-encoding= attribute), or just to tell Git tools what encoding to expect while retaining it as is (the encoding= attribute). By default neither attribute is set and no conversion or enforcement is done.
Some other types of Git objects (commits, annotated tags) are internally text-based and there Git does have a strong preference for UTF-8 by default. For example, commit messages are almost universally UTF-8 – many Git tools won't even correctly handle commits that have an encoding header.