Re: [PATCH] t3910: show failure of core.precomposeunicode with decomposed filenames

[Jeff King <peff@peff.net>]

On Mon, Apr 28, 2014 at 09:52:07PM +0200, Torsten Bögershausen wrote:

> To my knowledge repos with decomposed unicode should be rare in
> practice.  I only can speak for european (or latin based) or cyrillic
> languages myself:

I've run across several cases in the past few months, but only just
figured out what was going on. Most were tickets to GitHub support, but
we actually have such a case in our github/github repository. In most
cases, I think they were created on older versions of git on OS X,
either before core.precomposeunicode existed, or before it was turned on
by default. The decomposed form got baked into the tree (whatever the
user originally typed, git probably found out about it via "git add .").

I think reports are just coming in now because we didn't start turning
on core.precomposeunicode by default until v1.8.5, shipped in November.
And then, a person working on the repository would not notice anything,
since we only set the flag during clone. So it took time for people to
upgrade _and_ to make fresh clones.

> So for me the test case could sense, even if I think that nobody (TM)
> uses an old Git version under Mac OS X which is not able to handle
> precomposed unicode.

Even when they do not, the decomposed values are baked into history from
those old versions. So it is a matter of history created with older
versions not interacting well with newer versions.

-Peff