inexact rename detection warning on "git log -p"

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