[dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css
Jan Schneider
jan at horde.org
Wed Jan 7 17:50:15 UTC 2009
Zitat von Michael M Slusarz <slusarz at horde.org>:
> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> slusarz 2009-01-07 01:13:07 EST
>>>>
>>>> Modified files:
>>>> . annotate.php
>>>> templates/annotate header.inc line.inc
>>>> themes screen.css
>>>> Log:
>>>> Rework annotate screen - prevision revision number is not all that
>>>> important.
>>>> What is important is a link to the diff between the changing
>>>> revision and the
>>>> previous revision (the previous revision can be viewed in its entirety by
>>>> following the appropriate link on the diff page).
>>>
>>> Again, I strongly disagree. I use this all the time to navigate back
>>> through history until I find the actual revision where a change was
>>> really made, to skip revisions where a change was just cosmetically.
>>
>>
>> I agree with Jan on this (as well as the log info remaining in the
>> annotate view). IMO, an awful lot of the reason for me using annotate
>> (at least with non-git repos) is lost with these changes.
>
> Apparently the way I use annotate is completely different than
> everyone else (although, from past history, that doesn't surprise me
> :)) My problem with the way that everyone else does things is the
> following: if you click on the previous revision, and the change you
> are looking for is at line 5000, are you saying you have to scroll
> all the way down to line 5000 and then manually eyeball the section
> to see if it changes? That is entirely unacceptable to me. It makes
That's exactly how I use it, and the good thing is that it already
scrolls down for you to that line. It's not always accurate of course,
because the line number is just used 1:1, but it's a good approximate.
> a lot more sense to view a diff between the two revisions which,
> depending on the size of the commit, won't require scrolling at all.
> Then if the change is cosmetic only, you can click on the previous
> revision on the diff screen to go to that revision, and then you can
> click on Annotate on that page. Granted it does require an extra
> click to get to the next annotation, but on the flip side the server
> is doing all the comparing rather than your eyeballs.
>
> Still heartily disagree with the log tooltip. Given the existence
> of the diff icon now, the log tooltip is complete overkill and (with
> large files) is a total resource hog. I can actually view
> imp/lib/Compose.php now without it threatening to crash my browser
> (we're talking about a dual core CPU with many GB of memory) - which
> was one of the reasons that made me change this in the first place.
> Additionally, as previously mentioned, displaying log entries for
> git files that have been renamed is a non-trivial thing. git
> rev-list only displays revisions for the file as currently named.
> If changes were made before the file was renamed, then you have to
> go produce a log entry of that entire file and so-on until the git
> repo origin is reached.
I agree that the log tooltip is a huge resource hog and I alway
disliked that. But it's really helpful if you use history/annotation
like above, because you can often see with a single look whether the
linked diff is really what you are looking for.
I think it would be great to load the tooltip with an ajax request
instead, that would get us the full feature without the performance
loss.
> I guess the solution for the former is to re-add the Previous
> column. As for the log tooltip, if re-added, this would make most
> sense as a tooltip to the diff icon.
Agreed, a diff icon (if you talk about adding one to the annotate
view) is the better place for the log tooltip.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list