Re: Possible --remove-empty bug

From: Marco Costalba <mcostalba@gmail.com>
Date: Mar 17, 2006, 10:57 UTC
Message-ID: <e5bfff550603170257u21ee6583jabe5a6409cc40766@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0603131058270.3618@g5.osdl.org>

On 3/13/06, Linus Torvalds <torvalds@osdl.org> wrote:

Show 7 quoted lines

>
> However, to be honest, the only reason to ever use --remove-empty is for
> rename detection, and Frederik's approach of doing that through the
> library interface directly is actually a much superior option. So we might
> as well drop the compilcation of --remove-empty entirely, unless somebody
> has already started using it.
>

In case of a rather recent file --remove-empty option gives a good speed up in history loading with git-rev-list. So qgit uses that option.

Annotation in qgit it is little different from blame algorithm because it works from oldest revision to latest instead of the contrary. This is due because it calculates in one pass _all_ the annotations of all the different revisions of a given file, starting from file history, i.e. 'git-rev-list file_path' output.

The GUI interface of qgit let's the user quickly jump between two file revisions. So the corresponding annotations should be already prepared to make it snappy.

> The _real_ optimization would be to make the pathname based pruning be
> done incrementally instead of having to build up the whole tree.

Anything that speeds-up file git-rev-list history loading surely gives a big boost to all annotation/blame stuff. I have made some profiling on qgit (the public git repo version that is much faster, not the qgit1.1 released one) and I found that 50% to 70% of the time is spent on git-rev-list, of the remaining the 80% is spent on git-diff-tree -p patch loading and only a small amount is spent on actually calculate the annotation.

Of course these numbers can vary a little according to file/repo, but the big picture stays the same.

Marco