On Mon, 2014-01-27 at 08:33 +0700, Duy Nguyen wrote: > On Mon, Jan 27, 2014 at 4:10 AM, Joe Perches <joe@xxxxxxxxxxx> wrote: > > For instance (using the Linus' linux kernel git): > > > > $ time git log --follow -- drivers/firmware/google/Kconfig > /dev/null > > > > real 0m42.329s > > user 0m40.984s > > sys 0m0.792s > > > > $ time git blame -- drivers/firmware/google/Kconfig > /dev/null > > > > real 0m0.963s > > user 0m0.860s > > sys 0m0.096s > > > > It's not fair to compare blame and log. If you compare, compare it to > non follow version Perhaps not, but git blame does follow renames. $ git blame --help [] The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off). To follow lines moved from one file to another, or to follow lines that were copied and pasted from another file, etc., see the -C and -M options. > I tested a version with rename detection logic removed. It did not > change the timing significantly. To improve --follow I think we need > to do something about path filtering. Perhaps the log history could stop being read when a commit is found that creates the file without another file being deleted in the same commit. -- 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