git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>, git@vger.kernel.org
Subject: Re: [PATCH][RFC] git on Mac OS and precomposed unicode
Date: Mon, 09 Jan 2012 21:47:07 +0100	[thread overview]
Message-ID: <4F0B524B.8090203@web.de> (raw)
In-Reply-To: <7vty44eksp.fsf@alter.siamese.dyndns.org>

On 01/09/2012 08:29 PM, Junio C Hamano wrote:
> 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]

  reply	other threads:[~2012-01-09 20:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-07 19:59 [PATCH][RFC] git on Mac OS and precomposed unicode Torsten Bögershausen
2012-01-08  2:46 ` Junio C Hamano
2012-01-09 16:44   ` Torsten Bögershausen
2012-01-09 19:29     ` Junio C Hamano
2012-01-09 20:47       ` Torsten Bögershausen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-01-07 19:59 Torsten Bögershausen
2012-01-08  6:01 ` Miles Bader
2012-01-09 16:42   ` Torsten Bögershausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0B524B.8090203@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).