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 / \
Attachment:
signature.asc
Description: OpenPGP digital signature