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

Junio C Hamano wrote:

Sam Vilain [off-list ref] writes:

quoted

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.