Re: [PATCH] [RFC] Design for pathname encoding gitattribute [RESEND]

[Sam Vilain <sam.vilain@catalyst.net.nz>]

Junio C Hamano wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> 
>> On the chicken and egg thing, ...
>> ...  I do agree with Dscho's point that mixing encodings in a
>> repository is not necessarily a use case worth catering for.
> 
> Are you talking about "repository" as in "a specific clone", or
> "a project that can be cloned by many people and checked out to
> suit cloner's needs"?  I definitely agree that mixing encodings
> in a project (i.e. "paths in tree objects") does not make any
> sense _if_ clones of the projects _may_ want to check things out
> in different pathname encodings from each other.  And if all
> clones would want to check things out the same way, it does not
> really matter what encoding the paths in tree objects are.

I'm referring to the normalized form in the object database - ie what
affects the generated SHA1s - what you check it out to locally is a
developer's choice, and assuming that they can handle whatever issues
they create by doing this, then that should be fine.

> I am not absolutely sure if you are talking about mixing
> encodings depending on parts of the tree in a specific clone (my
> earlier "Documentação/ja/ お読み下さい" example).  I would
> certainly say it would be a very low priority for us to support
> such usage, as I imagine that multi-language trees would most
> likely be checked out in UTF-8 everywhere, but it _might_ be
> something people may find real need for.

Agreed - not something you want to condone, but if it's just as easy to
come up with a design that doesn't limit to one encoding for a whole
repository, it might help some people.

The use case for mixed encodings I had in mind was when you clone some
repository that's got them mixed, and you need to tell git the encoding
per-path to get the darned thing to behave sensibly for you (presumably
while you write a patch to submit upstream to fix it).

Sam.