Linus Torvalds wrote:
(Yes, from a technical standpoint making the annotation data bigger is a good thign: git simply has more useful information than CVS does. But the lack of information in CVS actually makes the "stupid interface" better, if only because you don't waste as much space on it).
I absolutely agree. My primary workflow around cvs annotate is about this: I read code and would like to know why this one snippet was introduced in the first place (or changed). So I go cvs annotate in my browser, and in parallel I display the cvs log, to actually see the commit message. Then I retrieve the diff output to see what happened, maybe starting the cycle again with an older version. What I want to illustrate is: No matter how much information you show in one line, you won't be able to fit all possible information. So my dream interface is a display which shows which runs of lines were changed together, and in which order the runs were changed. A temporary numbering of commits might help here (in CVS it is clear). Now when I identify a run, i'd like to have an easy way to retrieve the git log -p output. An additional blame should work on the parent of the commit associated with the current line (so that I can see how the line looked before this commit, and when this was changed). cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Attachment:
signature.asc
Description: OpenPGP digital signature