On Mon, 2014-01-27 at 08:33 +0700, Duy Nguyen wrote:
> On Mon, Jan 27, 2014 at 4:10 AM, Joe Perches <j...@perches.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to