Re: [PATCH] git-fetch --tags: deal with tags with spaces in them.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:08
"H. Peter Anvin" [off-list ref] writes:
H. Peter Anvin wrote:quoted
We can disallow whitespace, and we *have* to disallow at least newline due to the file format; I believe we should disallow all control characters (0-31, 127-159.)Actually, disallowing anything 128 and above means knowing the encoding system. If we enforce UTF-8, we should presumably disallow at the very least U+FFFE and U+FFFF too.
Hmph. I think enforcing (or rather supporting preferentially)
UTF-8 in log messages was alright, but enforcing UTF-8 tagnames
imply UTF-8 host pathnames because we do not currently convert
when we fetch refs from remote and store locally.
* git-clone-pack, git-fetch-pack and git-peek-remote run
git-upload-pack on the other end. Currently upload-pack
sends a list of refs read from the remote filesystem without
conversion, and:
(1) clone-pack uses the names without conversion to replicate
refs on the local filesystem.
(2) fetch-pack sends the names given on the command line,
and/or read from the local filesystem, to upload-pack
without conversion.
(3) fetch-pack and peek-remote outputs the names obtained
from the remote without conversion to stdout.
* over http, the encoding of the refnames client sees is what
is stored in project.git/info/refs on the remote. Currently,
update-server-info reads from the filesystem and writes this
file out without conversion. While walking the commits,
names are not used, so there is no refname encoding issues.
What we should do at this point is to declare that exchanging
refnames between systems is to happen after converting them to
UTF-8. And version 1.0 just assumes pathnames are UTF-8.
If people on systems with non UTF-8 pathnames cared enough, the
tools can be made aware of local pathname encodings, and taught
how to convert what for_each_ref() read from the filesystem, the
refspecs given from the command line, etc. to UTF-8. But that
can come later.