--- Petr Baudis <pasky@xxxxxxx> wrote:
> (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@xxxxxxxxx> said that...
> > --- Petr Baudis <pasky@xxxxxxx> 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. ;-)
Well understood.
Although, when I'm chasing after a problem, I care much about
tracing back through the commit history as opposed to who did
what and when, not until I've nailed the regressive commit (is when
I care who/what/when/how).
> 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.
Point taken.
Now since I don't want to turn blame2 into a circus, and since the whole
point of blame2 (over blame) was to stay away from it being a circus,
and to be fast and to the point, can we just keep git_blame() around
which gives you this extra information right in the main screen?
Luben
P.S. The alternative is to create a next git_blame{N+1}() each time
git_blameN() becomes git_blame{N-1}().
-
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