Out of idle curiosity, I cloned git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and chose to generate some statistics: $ find -not -iname '.git' | wc 52154 52154 1820305 That's a few files... $ git log | wc 8359290 37279781 334525133 Hmmm, well that's not too useful, let's see how many commits there are: $ git log | grep ^commit | wc 507296 1014592 24350208 and merges: $ git log | grep ^Merge: | wc 36019 111146 854397 I wonder what the total size of all changes are: $ git log --patch | wc warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. 93295818 366207219 3072072294 My bug report is in reference to the warning: It's not clear whether this warning just "warns" the user (hence the warning rather than an error) or whether it actually had an fault and didn't complete the operation successfully. It's also not clear whether the detection was aborted halfway through, or whether the work it has so far done has been discarded and is therefore idempotent if I *lowered* the renameLimit value (as opposed to raising it to fix the warning). Could the wording be changed to indicate that the operation continued without the rename detection? My preferred wording would be: warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. warning: continuing processing without inexact rename detection I'm a native English speaker and even I found the wording a little confusing -- although people used to gcc will know warning is informational and error is abortive, not all git users are aware of the distinction. Additionally, is the renameLimit something that could potentially be something dynamic (i.e. it inspects how much free RAM is available and increases the buffer if appropriate) or is that a conscious decision not to give the process "free reign"? Cheers, Matthew Walster -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html