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 / \ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2007-01-30 05:10:44 EST