rn-42: add article about clone and icase

Author: chriscool

rev_news/drafts/edition-42.md

@@ -25,9 +25,73 @@ This edition covers what happened during the month of July 2018.
 ### Reviews
 -->
 
-<!---
 ### Support
--->
+
+*[Git clone and case sensitivity](https://public-inbox.org/git/[email protected]/)
+
+Paweł Paruzel reported that he found some test files in his repo
+appeared modified just after a clone because he had files like
+"boolStyle_t_f" and "boolStyle_T_F" that differ only in case and was
+cloning on a case-insensitive Mac.
+
+He suggested having `git clone` throw an exception when files that
+differ only in case are cloned to a case insensitive system.
+
+Brian Carlson replied that this would make it impossible to clone such
+a repository on a case-insensitive system while the current behavior
+might still result in a functional repo.
+
+Brian also suggested using something like `test $(git status --porcelain | wc -l) -eq 0`
+to check that a repo is unmodified after clone.
+
+Duy Nguyen agreed with Brian and proposed a patch that uses sparse
+checkout to hide all the paths that fail to checkout because of the
+filesystem. Duy's patch also warns to tell the user what happens.
+
+Jeff King, alias Peff, replied to Duy suggesting just warning and
+advising the user. And Duy followed up with a modified patch that does
+just that.
+
+Simon Ruderich commented that the advice message in Duy's patch should
+list the problematic file names to help users.
+
+Peff agreed with Simon and wondered if it was better to detect at
+checkout time if a file already exists on the filesystem rather than
+checking before the checkout. Peff also noted that Duy's patch used
+strcasecmp() to check if filemanes diff only by case, but in some
+cases, especially related to utf8 names, a filesystem could use
+complex folding rules which we would need to follow.
+
+Brian replied to Peff saying that it was indeed possible to detect the
+issue at checkout time, and Duy replied that it was actually what his
+patch was doing.
+
+Duy, Peff and Jeff Hostetler then agreed that it would be difficult to
+follow complex folding rules that a filesystem might use.
+
+Duy then started sending [a real patch in its own email](https://public-inbox.org/git/[email protected]/).
+
+Junio Hamano chimed in to suggest a different implementation and a
+long discussion thread followed about how to best find all the
+colliding paths.
+
+Duy sent [a version 2 of his patch](https://public-inbox.org/git/[email protected]/).
+
+The previous long discussion thread continued following this patch though.
+
+Duy sent [a version 3](https://public-inbox.org/git/[email protected]/)
+that actually tries to find all the colliding paths on "UNIXy platforms"
+and then [a version 4](https://public-inbox.org/git/[email protected]/).
+
+A discussion and a patch about clarifying the documentation of the
+`core.checkStat` config option followed.
+
+Duy then recently sent [a version 5](https://public-inbox.org/git/[email protected]/)
+which tries to find all the colliding paths on Windows too,
+and [a version 6](https://public-inbox.org/git/[email protected]/)
+to address a few more comments.
+
+It looks like the latest version will be merged to the "next" branch soon.
 
 <!---
 ## Developer Spotlight: