--- Petr Baudis <pasky@xxxxxxx> wrote:
> Dear diary, on Thu, Oct 05, 2006 at 10:13:15AM CEST, I got a letter
> where Junio C Hamano <junkio@xxxxxxx> said that...
> > It's been a while since we lost git_blame from %actions list. I
> > am wondering maybe it's time to remove it, after 1.4.3 happens.
>
> I will not mourn git-annotate disappearance (perhaps it could stay an
> alias to git-blame -c; I don't like this UI-wise but we already do this
> kind of thing with git-log / git-whatchanged). I still like gitweb blame
> better than blame2 but I'll just patch blame to look like blame2 (or
> better) and be happy with that.
That's exactly what I don't want to happen. blame2 is much less
bloated than blame both in code and in visual appearance and in using
git. And this was the whole point: quick, short, fast and straight
to the point.
I'd like to keep the blame interface as simple as possible, more
window estate given to the code lines, and as little as possible to
the commit id: a clickable commit-8 and now we also have clickable
line_no to show us the state of the file, is more than enough.
So far, blame2 has been by far the better "annotate" (as it is called
in the other SCMs) interface I've seen in four other SCMs (some proprietary).
Let's keep it like this.
When data-mining code, what I'm interested in is: where did this line
of code come from (commit-8), is it a part of a larger chunk (zebra
coloring) and how it relates to the surrounding code. Blame2 is more
than efficient at this.
Luben
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
-
To unsubscribe from this list: 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