From: Jeff King <peff@peff.net>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: [PATCH] t3910: show failure of core.precomposeunicode with decomposed filenames
Date: Mon, 28 Apr 2014 12:16:31 -0400 [thread overview]
Message-ID: <20140428161630.GA9435@sigill.intra.peff.net> (raw)
If you have existing decomposed filenames in your git
repository (e.g., that were created with older versions of
git that did not precompose unicode), a modern git with
core.precomposeunicode set does not handle them well.
The problem is that we normalize the paths coming from the
disk into their precomposed form, and then compare them
against the literal bytes in the index. This makes things
better if you have the precomposed form in the index. It
makes things worse if you actually have the decomposed form
in the index.
As a result, paths with decomposed filenames may have their
precomposed variants listed as untracked files (even though
the precomposed variants do not exist on-disk at all).
This patch just adds a test to demonstrate the breakage.
Some possible fixes are:
1. Tell everyone that NFD in the git repo is wrong, and
they should make a new commit to normalize all their
in-repo files to be precomposed.
This is probably not the right thing to do, because it
still doesn't fix checkouts of old history. And it
spreads the problem to people on byte-preserving
filesystems (like ext4), because now they have to start
precomposing their filenames as they are adde to git.
2. Do all index filename comparisons using a UTF-8 aware
comparison function when core.precomposeunicode is set.
This would probably have bad performance, and somewhat
defeats the point of converting the filenames at the
readdir level in the first place.
3. Convert index filenames to their precomposed form when
we read the index from disk. This would be efficient,
but we would have to be careful not to write the
precomposed forms back out to disk.
4. Introduce some infrastructure to efficiently match up
the precomposed/decomposed forms. We already do
something similar for case-insensitive files using
name-hash.c. We might be able to adapt that strategy
here.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t3910-mac-os-precompose.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
index e4ba601..23aa61e 100755
--- a/t/t3910-mac-os-precompose.sh
+++ b/t/t3910-mac-os-precompose.sh
@@ -140,6 +140,16 @@ test_expect_success "Add long precomposed filename" '
git add * &&
git commit -m "Long filename"
'
+
+test_expect_failure 'handle existing decomposed filenames' '
+ echo content >"verbatim.$Adiarnfd" &&
+ git -c core.precomposeunicode=false add "verbatim.$Adiarnfd" &&
+ git commit -m "existing decomposed file" &&
+ >expect &&
+ git ls-files --exclude-standard -o "verbatim*" >untracked &&
+ test_cmp expect untracked
+'
+
# Test if the global core.precomposeunicode stops autosensing
# Must be the last test case
test_expect_success "respect git config --global core.precomposeunicode" '
--
1.9.1.656.ge8a0637
next reply other threads:[~2014-04-28 16:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 16:16 Jeff King [this message]
2014-04-28 19:17 ` [PATCH] t3910: show failure of core.precomposeunicode with decomposed filenames Junio C Hamano
2014-04-28 19:35 ` Jeff King
2014-04-28 19:52 ` Torsten Bögershausen
2014-04-28 20:03 ` Jeff King
2014-04-28 20:49 ` Torsten Bögershausen
2014-04-29 3:23 ` Jeff King
2014-04-29 7:39 ` Torsten Bögershausen
2014-04-29 3:15 ` Jeff King
2014-04-29 17:12 ` Junio C Hamano
2014-04-29 18:02 ` Jeff King
2014-04-29 18:49 ` Junio C Hamano
2014-04-29 19:46 ` Jeff King
2014-04-30 14:57 ` Torsten Bögershausen
2014-05-04 12:04 ` Torsten Bögershausen
2014-05-04 6:13 ` Torsten Bögershausen
2014-05-05 21:46 ` Jeff King
2014-05-06 10:11 ` Erik Faye-Lund
2014-05-07 19:16 ` 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=20140428161630.GA9435@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/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).