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

On 08.01.12 03:46, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> Implementation:
>> Two files are added to the "compat" directory, darwin.h and darwin.c.
>> They implement basically 3 new functions:
>> darwin_opendir(), darwin_readdir() and darwin_closedir().
> 
> I haven't looked at the patch yet but that sounds exactly the right way to
> go about this. Nice.
> 
>> No decomposed file names in a git repository:
>> In order to prevent that ever a file name in decomposed unicode is entering
>> the index, a "brute force" attempt is taken:
>> all arguments into git (technically argv[1]..argv[n]) are converted into
>> precomposed unicode.
> 
> 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, and match them against the paths in the index, the latter of
> which you are keeping in the canonical form, so you would want the argv[]
> also be in the same form, and applying your argv_precompose() would be a
> sensible way to do so, no?

Thanks Junio for catching this.
I added a new test case as well as fixed the code.

> I would also suspect that the cleanest way to implement it is to replace
> the main() entry point (see how compat/mingw.h does this).

We only need to that argv conversion in git.c, (and not in daemon.c), so I sticked
to the old model for V1.
I send a new patch soon
/Torsten

  reply	other threads:[~2012-01-09 16:53 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 [this message]
2012-01-09 19:29     ` Junio C Hamano
2012-01-09 20:47       ` Torsten Bögershausen
  -- 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=4F0B196B.8010904@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.