Re: [PATCH/RFC 3/4] git check-ref-format --print

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH/RFC 3/4] git check-ref-format --print

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:32

Jonathan Nieder [off-list ref] writes:
In the future, it would be very nice if this command could be
modified to transform Unicode ref names to some appropriate
normalization form, to make Unicode ref names usable in Mac OS X,
too, and less confusing everywhere.
I do not disagree with a desire to help fixing the unicode insanity on
that platform, but I suspect that check-ref-format is a wrong place to
tackle the issue.  You would need a similar filter for outputs from the
likes of ls-files and "diff --name-only", iow, anything that deal with
pathnames, no?

It would have be something like "check-ref-format --print | iconv ..."
pipeline (conceptually, if not forcing the pipeline to the end users, that
is).

Also are people happy with "--print"?  I was waiting for others to reword
it to "--normalize" or something like that.  In your documentation you
explain it to "canonicalize", and in your tests you name the output
"normalized".  I am fine with either wording, but would like to see us
using only one, not both.

Thanks.

Re: [PATCH/RFC 3/4] git check-ref-format --print

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:47:32

Junio C Hamano wrote:
I do not disagree with a desire to help fixing the unicode insanity on
that platform, but I suspect that check-ref-format is a wrong place to
tackle the issue.  You would need a similar filter for outputs from the
likes of ls-files and "diff --name-only", iow, anything that deal with
pathnames, no?

It would have be something like "check-ref-format --print | iconv ..."
pipeline (conceptually, if not forcing the pipeline to the end users, that
is).
GNU iconv does not write the various Unicode normalization forms, so it
would have to be something like "check-ref-format --print | charlint ..."
instead.  Regardless of the filesystem, it seems reasonable to consider é
(U+00e9) and é (U+0065 + U+0301) the same character when it appears in a
ref name, and one way to achieve this would be to pick one normalization
form and stick to it.  This does not seem so different from stripping out
empty path components.

As a side effect, that would deal with OS X’s strange handling of unicode
filenames for .git/refs/*.  Now that I think about it, if fighting OS X
were the only problem that needed to be solved, I don’t think I’d like
this solution so much.  The analogous solution to the also unsolved issue
of case insensitive filesystems is to force all ref names to lowercase.
Do we want to do that?  (The case insensitivity issue might not be as bad,
since the relevant filesystems will at least _preserve_ the case of
filenames in .git/refs.  Should we copy them and smudge new ref names to
match known ones that differ only in case?  Just thinking about the
problem makes me cringe.)

Coping with the unicode filename craziness in the working tree is a
separate issue, though probably a more important one.  I think Linus set
up a framework for solving it in
<http://thread.gmane.org/gmane.comp.version-control.git/77827>.

Regards,
Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help