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

Re: [PATCH][RFC] git on Mac OS and precomposed unicode

From
Torsten Bögershausen <tboegi@web.de>
Date
Jan 9, 2012, 20:47 UTC
Message-ID
<4F0B524B.8090203@web.de>
In-Reply-To
<7vty44eksp.fsf@alter.siamese.dyndns.org>
On 01/09/2012 08:29 PM, Junio C Hamano wrote:
Show 44 quoted lines
> Torsten Bögershausen<tboegi@web.de>  writes:
>
>> On 08.01.12 03:46, Junio C Hamano wrote:
>> ...
>>> That also sounds sensible, but...
>>>
>>>> This is done in git.c by calling argv_precompose() for all commands
>>>> except "git commit".
>>>
>>> ... I think it generally is a bad idea to say "all except foo". There may
>>> be a reason why "foo" happens to be special in today's code, but who says
>>> there won't be another command "bar" that shares the same reason with
>>> "foo" to be treated specially? Or depending on the options, perhaps some
>>> codepath of "foo" may not want the special casing and want to go through
>>> the argv_precompose(), no?
>>>
>>> After all, "git commit -- pathspec" will have to get the pathspec from the
>>> command line,...
>>
>> Thanks Junio for catching this.
>> I added a new test case as well as fixed the code.
>
> I think you are sidestepping the real issue I raised, which is:
>
>      What is the reason why you do not want to feed the precompose helper
>      with some arguments to 'git commit', while it is OK to pass all
>      arguments to other commands through precomposition?
>
> I admit it was my fault that I did not spell it out clearly in my
> response.
>
> I understand that arguments other than pathspec and revs could be left in
> decomposed form, but is there any harm in canonicalizing any and all
> command line parameters given in decomposed form consistently into
> precomposed form? What problem are you trying to solve by special casing
> "git commit"? That is the real question to be answered, as there may be
> other commands some of whose arguments may not want to be canonicalized
> due to the same reason, but you simply overlooked them. When other people
> need to fix that oversight, they need a clearly written criterion what
> kind of arguments should not be fixed and why.
>
> And the reason cannot be a desire to pass the value to "--message"
> argument intact [*1*]; it is not like osx cannot handle text in
> precomposed form, right?
The short answer for treating "git commit" special:
   The test suite didn't pass any more. (t4201-shortlog.sh)
   This seems more and more to be a bad excuse...
The long answer:
   I have to look into that more deeply.

Thanks for your replies. /Torsten

     (And yes, Mac OS can handle precomposed unicode (at least the
      western european code points))
[snip]
Previous: Junio C Hamano
Message 5 of 5 in “[RFC] git on Mac OS and precomposed unicode”
  1. [RFC] git on Mac OS and precomposed unicodeTorsten Bögershausen, Jan 7, 2012
  2. Junio C HamanoJan 8, 2012
  3. Torsten BögershausenJan 9, 2012
  4. Junio C HamanoJan 9, 2012
  5. Torsten BögershausenJan 9, 2012

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.