Re: Following renames

From: Marco Costalba <mcostalba@gmail.com>
Date: Mar 27, 2006, 11:19 UTC
Message-ID: <e5bfff550603270319w20796918wc8f8fe30a6c5627@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0603270005330.15714@g5.osdl.org>

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

Show 15 quoted lines

>
>
> On Mon, 27 Mar 2006, Marco Costalba wrote:
> >
> > Historic Linux test (63428 revisions)
> >
> > File: drivers/net/tg3.c
> > Revisions that modify tg3.c : 292
> >
> > With qgit
> > 15s to retrieve file history (git-rev-list)
> > 19.5s to annotate (git-diff-tree -p, current GNU algorithm, not new faster one)
>
> .. and it does absolutely _nothing_ while it's doing that, does it?
>

yes, it's true.

Show 12 quoted lines

> > $ time git-whatchanged HEAD drivers/net/tg3.c > /dev/null
> > 98.01user 2.44system 1:46.19elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (797major+43033minor)pagefaults 0swaps
>
> In contrast, git-whatchanged will start outputting the recent changes
> immediately.
>
> And that's the point. Almost always, we're interested in the _recent_
> stuff. The fact that it takes longer to get the old history  is not very
> important. You generally don't ask "what changed in this file" for a file
> that hasn't changed in five years.
>

We could run git-rev-list with a time range specifier (changes of last year as example) by default so to have fast results and run all time history _only_ on request.

This perhaps could solve the fast output for recent revs problem, if this is the problem.

I still think the problem with annotation is that you don't see patches that _remove_ lines of code, you need the whole diff for this.

Marco