Re: git blame vs git log --follow performance

From: Joe Perches <joe@perches.com>
Date: Jan 27, 2014, 02:00 UTC
Message-ID: <1390788011.20150.32.camel@joe-AO722>
In-Reply-To: <CACsJy8B4dkjae3tL+_JvD63HCoi_-nNWYGvT3xRTqi8UpYX95g@mail.gmail.com>

On Mon, 2014-01-27 at 08:33 +0700, Duy Nguyen wrote:

Show 18 quoted lines

> On Mon, Jan 27, 2014 at 4:10 AM, Joe Perches <joe@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.