Re: Does GIT require property like Subversion?

From: Liu Yubao <yubao.liu@gmail.com>
Date: Oct 9, 2006, 02:53 UTC
Message-ID: <4529B9C7.7000000@gmail.com>
In-Reply-To: <200610081752.10940.robin.rosenberg.lists@dewire.com>

Sorry, I forgot to reply all.

Robin Rosenberg wrote:

Show 22 quoted lines

> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:
>> File content encoding is something (if it is outside US-ASCII of course)
>> that you would want either to have some default convention, or have it
>> embedded in the file itself (like XML, HTML, or Emacs' file variables)
>> to be able to read file _outside_ SCM.
> Except for CR/LF, this is best solved outside of the SCM. There aren't that
> may tools/users to warrant the complexity or performance hit I imagine to 
> solve it.
> 
>> Path name encoding is something that is global property of a repository,
>> I think. We have i18n.commitEncoding configuration variable; we could
>> add i18n.pathnameEncoding quite easily I think (and some way for Git to
>> detect current filesystem pathname encoding, if possible). Although
>> BTW I think that i18n.commitEncoding information should be made persistent,
>> and copied when cloning repository.
> 
> *I* think git should use UTF-8 internally. Always. Clients could then have
> the option to convert to local conventions.
> 
> Same for pathname. Internally all paths should be UTF-8 encoded. Encoding 
> commit info that way would make the i18n option obsolete also.
>

I am afraid it's not a good idea to convert file content to UTF-8 encoding as GIT can manage non-text file, it's not safe to modify file content stealthily by a VCS.

But I agree to use UTF-8 for path name in tree object, or add an encoding property(not a user defined property) to the head of tree object, so GIT won't do useless enc -> UTF-8 -> same_enc conversion. The second way has a fault: two tree objects with same content in different encoding have different SHA1 digests.

Show 9 quoted lines

> I have a patch for both these, but it's very ugly and probably has some memory 
> management problems, so I'll refrain from submitting for now. Knowing that it 
> exists may perhaps serve as starting point for discussion. It encodes 
> filenames in UTF-8 using LC_CTYPE as the local encoding, as well as commit 
> messages. An exception is when something looks like UTF-8, in which case it 
> will not convert input to git. When UTF-8 cannot be converted to the local 
> encoding on it's way out of git, the data remains in UTF-8 format. Branch and 
> tags names are not managed (yet, at least).
>

 >
Good, hope GIT can deal with path names that are not in 8859_1 or UTF-8 encoding.