Re: More precise tag following

Johannes Schindelin wrote:

It is slower than Subversion's counterpart, just because SVN's blame 
sucks. You cannot find out the _relevant_ information easily, i.e. once 
you merged something, the _merge_ gets attributed for the change (at least 
the last time I tried it).

So, don't blame blame for being useful in git.

Your reasoning is backwards.  Git's blame (or fwiw, rev-list path.name) is not slower because it is doing a better job (I can't tell, I don't use svn), but because it uses an algorithm which doesn't scale.  rev-list and blame are O(number of commits between HEAD and root) and not O(number of commits affecting path).  It might be sufficient for git.git, but certainly not for projects with a long history.  we are talking KDE, FreeBSD, OOo, something like this.  They each got about 400k commits.  It takes literally *minutes* to get a rev-list or a blame for a certain path.  The algorithm simply does not scale.  And this has nothing to do with superior output, because hg does it in O(num_of_file_revs), so it *can* be done.

Of course, you could introduce a cache, but then, I don't run blame _that_ 
often.

I don't think a cache is the right way.  I'd call the right idea "auxillary information".

Besides, we already introduced an orthogonal historisation by reflogs, and 
your method would not cope gracefully with that, would it?

I don't see how reflogs can play into this.  After all we're talking about the series of commits the blob experienced to get into its current state, not the series of actions it took this repo to contain this blob.

cheers
  simon

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \