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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
