On Sun, Mar 26, 2006 at 12:07:17PM +0200, Petr Baudis wrote: > Dear diary, on Sun, Mar 26, 2006 at 05:19:50AM CEST, I got a letter > where Linus Torvalds <torvalds@xxxxxxxx> said that... > > On Sun, 26 Mar 2006, Petr Baudis wrote: > > > > > > In [1], Linus suggests a non-core solution. Unfortunately, it doesn't > > > fly - it requires at least two git-ls-tree calls per revision which > > > would bog things down awfully (to roughly half of the original speed). > > > > No it doesn't. It requires one git-ls-tree WHEN SOMETHING IS RENAMED. > > > > In other words, basically never. > > Huh? I don't see that now (and caps don't help me see it better). That's > certainly not what is in [1], and I don't see _how_ to detect the > renames in this case, and what would I be actually doing git-ls-tree for > when I've already detected the rename. Based on [1], I'd be doing > git-ls-tree merely to detect that a file _disappeared_ in the first > place, I have to do other stuff to detect the renames themselves. > > Dear diary, on Sun, Mar 26, 2006 at 09:35:02AM CEST, I got a letter > where Ryan Anderson <ryan@xxxxxxxxxxxxxx> said that... > > A simple example is the first loop in git-annotate.perl. (Which was > > basically written by Linus, I just translated it from a > > shell/pseudo-code example into Perl) > > Thanks for the hint. Unfortunately, this is precisely the thing I want > to avoid, that is essentially reimplementing part of git-rev-list - to > do something good, I would have to do my own toposort and merge by date > between parallel lines. OTOH, I might just construct a large revlist > commandline specifying all the segments I'm interested in and see what > happens when I run that. > > Besides, doing it in shell would be pretty ugly job (forcing me to > finally rewrite it in perl is not a bad thing but that'd be a somewhat > larger project since I share various common routines with other cg > tools, etc). > If you decide to modify rev-list to do rename tracking you might want to have a look at how this is done in blame.c. git-blame only tracks one file (since that is what it needs) but I think it should be possible to track multiple files with a similar approach. - Fredrik - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html