Re: Following renames

From: Linus Torvalds <torvalds@osdl.org>
Date: Mar 27, 2006, 16:52 UTC
Message-ID: <Pine.LNX.4.64.0603270848200.15714@g5.osdl.org>
In-Reply-To: <e5bfff550603270319w20796918wc8f8fe30a6c5627@mail.gmail.com>

On Mon, 27 Mar 2006, Marco Costalba wrote:

Show 9 quoted lines

> >
> > 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.

Yes.

However, what I've been meaning to do (but just haven't had the time and energy for so far) is to fix "git-rev-list" with a path limiter.

Right now that always causes things to be totally serialized, and the revision walking will first look up _all_ the history (well, it will prune out the merges) before starting to output stuff.

So right now in order for "git-whatchanged" to be fast and incremental, it doesn't do any path limiting with git-rev-list at ALL, and does it all in git-diff-tree. Which is horrid.

> 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.

Well, that's just another reason "annotate" sucks.

If you select a range of lines, my suggested tool _would_ show you lines that got removed there, and git-whatchanged does it quite well.

I really think "annotate" is _fundamentally_ a broken operation. It's not what any sane developer actually wants, and it has serious limitations (ie it depends on whole history, and it cannot show removals well).

		Linus