inexact rename detection warning on "git log -p"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]