I configured the origin remote of my dotfiles repo with a URL git could not dial directly:
[remote "origin"]
url = self://...self:// is a fake scheme (and ... is the repo’s actual name). Git’s transport never sees it—url.insteadOf rewrites it before transport selection runs. The tracked config carries the canonical mapping:
[include]
path = config-local
[url "ssh://git@github.com/anthonyrisinger/"]
insteadOf = self://That alone would just be indirection. The point is the [include] above it: an optional, gitignored config-local can redefine what self:// means on this machine. The shipped example:
[url "/etc/00000000000000000000000000000000/"]
insteadOf = self://
[url "https://github.com/xtfxme/"]
pushInsteadOf = self://Fetches resolve to a local bare mirror on the filesystem; pushInsteadOf overrides the fetch rewrite for pushes only, so those still go to the canonical hub. One symbol, resolved per machine, split by direction. The 32 zeros are a template—git ellipsis.init substitutes the machine’s D-Bus machine-id—and a systemd oneshot unit and timer kept exactly that mirror fresh at /etc/%m/... (%m is systemd’s machine-id specifier), fetching every eight hours so shell startup never waited on the network.
The caveat is the tie-break. Both insteadOf rules rewrite the identical prefix self://. Git documents that the longest match wins, but says nothing about equal-length ties; in practice the first-seen rule wins, and the [include] sits above the GitHub stanza, so a present config-local captures fetches. Absent, the include silently no-ops and the tracked rule is the only match. The whole scheme leans on that ordering as an implementation behavior rather than a documented tie-break.