Git Rev News: Edition 42 (August 22nd, 2018)

Welcome to the 42nd edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on

This edition covers what happened during the month of July 2018.



Last month’s edition discussed the state of NewHash work, i.e. the process of selecting Git’s next-generation hash function. This discussion has concluded with the selection of SHA-256. An update to hash-function-transition.txt to change NewHash to SHA-256 is queued in the next branch.


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 filenames 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.

Junio Hamano chimed in to suggest a different implementation and a long discussion thread involving Torsten Bögershausen, Elijah Newren, Duy, Junio, Peff and Jeff Hostetler followed about how to best find all the colliding paths.

Duy sent a version 2 of his patch.

The previous long discussion thread continued following this patch though.

Duy sent a version 3 that actually tries to find all the colliding paths on “UNIXy platforms”.

Szeder Gábor found small issues in the patch, so Duy sent a version 4.

Comments from Torsten started a discussion about clarifying the documentation of the core.checkStat config option which was addressed by a separate patch from Duy and Junio.

Duy then recently sent a version 5 which tries to find all the colliding paths on Windows too, and a version 6 to address a few more comments from Junio and Torsten.

It looks like the latest version will be merged to the “next” branch soon.

Developer Spotlight: Derrick Stolee


Other News


Light reading

Git tools and sites


This edition of Git Rev News was curated by Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Gabriel Alcaras <> with help from Derrick Stolee and Ævar Arnfjörð Bjarmason.