git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Oct 13, 2009, 04:49 UTC
Message-ID
<20091013044929.GA30342@progeny.tock>
In-Reply-To
<7vococ6v73.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 9 quoted lines
> 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

Previous: Junio C HamanoNext: Jonathan Nieder
Message 15 of 17 in “disallow refs containing successive slashes”
  1. disallow refs containing successive slashesJens Lehmann, Oct 10, 2009
  2. Junio C HamanoOct 10, 2009
  3. Jens LehmannOct 11, 2009
  4. Junio C HamanoOct 11, 2009
  5. Jonathan NiederOct 12, 2009
  6. Nanako ShiraishiOct 12, 2009
  7. 0/4 plumbing to help fix git-guiJonathan Nieder, Oct 12, 2009
  8. 1/4 Add tests for git check-ref-formatJonathan Nieder, Oct 12, 2009
  9. 2/4 Documentation: describe check-ref-format --branchJonathan Nieder, Oct 12, 2009
  10. 3/4 git check-ref-format --printJonathan Nieder, Oct 12, 2009
  11. Shawn O. PearceOct 12, 2009
  12. Junio C HamanoOct 12, 2009
  13. Shawn O. PearceOct 12, 2009
  14. Junio C HamanoOct 12, 2009
  15. Jonathan NiederOct 13, 2009
  16. 4/4 check-ref-format: simplify --print implementationJonathan Nieder, Oct 12, 2009
  17. Jonathan NiederOct 12, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.