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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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. ;-)

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.

There should be no additional load caused by this since we already
extract this information anyway - we show it as a tooltip.

-- 
				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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]