On Thursday, March 20, 2014 01:45:21 PM Junio C Hamano wrote: > There hasn't been any argument for this patch, either. > > It is not like we are still in year 2007; timing result in a small > project like Git itself is not a good enough argument to change a > well established default at this late in the game, especially when > there are ways like command line options for users to specify their > preferred settings. The main reason why I submitted it is because the current behavior is very unintuitive when you split big files into smaller ones. Like the one that was done in 2cf565c. If you do: $ git checkout 2cf565c $ git blame -C -C -C -M Documentation/git-ls-files.txt then blame will not be able to detect any moves, even though big chunks have been moved without whitespace changes. Worse is that if you do $ git gui blame Documentation/git-ls-files.txt then that won't see any movies either, and there is no way to make git gui blame use --minimal. I spent a lot of time at $work trying to code-review a big split like this, wondering why "git gui blame" and "git blame -C -C -C -M" couldn't detect moves when complete functions had been moved with no changes (not even whitespace). So by making it default it will hopefully help someone else from losing time investigating this. It wasn't until I did a bisect on git, finding 582aa00 and later googling for XDF_NEED_MINIMAL to find 059a500, that I found out about --minimal. Which is not documented anywhere. I guess it can be argued for just documenting --minimal and either patching "git gui blame" to use it, or make it configurable. However I think the current default is really confusing, and the reason for changing it back in 2007 was for performance, so that was what I tried to focus on, hopefully showing that there aren't any noticeable differences. /Michael -- 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