Re: [PATCH] git-fetch --tags: deal with tags with spaces in them.

From: Junio C Hamano <junkio@cox.net>
Date: Oct 12, 2005, 18:57 UTC
Message-ID: <7vslv6ef6q.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <434D3000.5020601@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> writes:

Show 8 quoted lines

> H. Peter Anvin wrote:
>> 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.