Re: perhaps time to remove git_blame from gitweb, and git-annotate?

> (Trimmed cc list to people caring about gitweb.)
> 
> Dear diary, on Fri, Oct 06, 2006 at 08:55:29PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > 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.
> 
> And _I_ like to have some general idea about who and when touched given
> line of code, without having to click on a bunch of commit ids or spend
> a minute hovering over them patiently. ;-)

> If you really feel strongly about it, we should be able to make the
> individual columns hideable at view time, e.g. by a tiny bit of
> javascript just changing the display CSS property, which would be really
> comfortable. My idea about the output would be cg-log -s format, which
> is still reasonably tense. OTOH, there's still some space to burn in the
> Line column.