But from there, how to get back in history for that line 'Annotate This Version' is greyed out. Then, I can right-click the line on the annotations gutter and say 'Annotate This Version' which will give me the latest change for that specific line. But then I get only to see the latest change. So if you're wondering who to blame, now you know. I know there is Source Control > Annotate. This feature is called "annotate" in Team System source control, but it's called "blame" in Subversion and in Vault. Sometimes you just want to know who wrote this crap, and having that information directly next to the code in your editor saves many tedious steps of manually tracking down the owner of those particular lines.
#Git annotate vs git blame full#
Clicking on the revision number brings up the full details dialog for that checkin.Īlthough I have mixed feelings about source control integration with the IDE, I think this is a fairly compelling argument in favor of it. Annotations for the most recently changed lines in the file are marked with bold. But I think it is important to clarify that this refers to lines modified in the current revision of the file, not the current revision of the repository. You can supply git blame a specific commit ID to. Annotations for lines modified in the current revision, are marked with bold type and an asterisk. Hovering over the revision number reveals a tooltip containing any checkin comments associated with that change. Most Git repository managers like GitHub make it easy to annotate files using git blame in your browser. The last person to change any particular line is identified right there, next to the lines they changed, along with the date and revision number. The upcoming Visual Studio 2008, or at least the Team System flavor of it, finally delivers a feature I've wanted for years: it can display the code side-by-side with the person who last changed that code. But figuring out who's actually responsible for that crappy code takes some detective work. There's a knee-jerk predisposition to look at code you didn't write, and for various reasons large and small, proclaim it absolute crap. It's still true, more than 25 years later. annotate from a certain commit See 'Git blame prior commits': git blame -c fe25b6d - src/options.cppor annotate from a certain date: git blame -c -since3.weeks - foo Note bis: I prefer git blame -c to git annotate.
It's quoted from a much earlier book, Stan Kelley-Bootle's The Devil's Dp Dictionary, which was published in 1981. I first read this in the original 1993 edition of Code Complete. My program (n): a gem of algorithmic precision, offering the most sublime balance between compact, efficient coding on the one hand, and fully commented legibility for posterity on the other. Your program (n): a maze of non-sequiturs littered with clever-clever tricks and irrelevant comments.
0 kommentar(er)
