Use the `net/git-checkout` library to support git repository servers
in general, instead of supporting only GitHub. A HTTP(S) source is
treated as a repository source when it ends with the ".git" suffix.
The new argument is needed to reliably write to a tmp file, for
example, where the existence of the tmp file prevents other processes
from using the same name.
Git-based hosting services most commonly support the smart HTTPS
protocol, which carries "git://"-format payload in a fairly straightforward
way. (Supporting the dumb protocol looks much more difficult.)
The `net/git-checkout` library implements enough of `git clone` to
extract a tree from a repository that is accessed via the "git://"
protocol. It doesn't preserve a local clone, and it attempts to
download only the slice of the repository that is needed for the
requested tree (depending on how the tree is referenced).
In particular, a #f argument can make sense if the length is 0.
Technically, a byte string's byte array is supposed to be nul-terminated,
but many uses of byte strings get away without that terminator. I've
adjust the documentation to note that `bytes-copy` will work with a
non-terminated byte string.
Merge to v6.1.1
The fixup is not allowed to changed the virtual
address of a SHT_PROGBITS section, so a expanded
".dynstr" section might have to be moved to a
virtual address after everything else.
This bug could result in weird "cannot re-define a constant: lifted.0.2"
errors, or probably even worse collsisions of definitions, but I think
only in a namespace created from `module->namespace`.
So far, I haven't been able to create a reasonably small test,
because so many things have to line up in just the right way.
Merge to v6.1.1
If you set the locale to something like "us_EN.1252", then
"1252" was returned as the encoding, but "CP1252" is more likely
to be recognized by `bytes-open-converter`.
Also, document representation information on paths. In particular,
explain that Unix and Mac OS X paths are natively byte strings, while
Windows paths are natively UTF-16 code-unit sequences. The byte-string
representation of a Windows path is a UTF-8-like encoding of the UTF-16
code-unit sequence, which is why it makes no sense to convert it using
the current locale's encoding.
Sounds like a bad name, but I don't have anything better. It's not some
"current-...-print" thing since it works on the sexpr that is intended
to be pretty-printed. So I went with the above.
