On Mon, 2018-01-29 at 13:30 +0000, Joseph Myers wrote: > On Mon, 29 Jan 2018, Richard Stallman wrote: > > But I do have a checkout of Emacs, on which I could try git blame. > > Can you please tell me exactly what to try, so as to see what it > > does? > > In the checkout, do "git blame <file>", for any <file> you want to > see information about. That will show which commit resulted in the > present state of each line of the file. > > Sometimes the most recent commit isn't the interesting one. Say > you're looking at a piece of code and the most recent commit to it > just reindented the code, but you want to find out about changes > before the reindentation[*]. The git blame output will have lines > looking like: > > abcdef01 (Author date line number) source line > > Say that's one of the lines from the reindentation commit and you > want to see changes to that code from before the reindentation. Then > you can do: > > git blame <file> abcdef01^ > > (note the ^, meaning "parent commit"), which will produce output for > the state of the file immediately before commit abcdef01, showing > details of the commits responsible for that state.
Another option, if course, is to use Emacs VC mode. I use Magit (separately-developed Git interface) in Emacs for most of my Git interaction, but I find VC mode's blame support for Git to be very good and usually I use that. To use it, use C-x v g (vc-annotate) while visiting a file. It will show a buffer with each line of the file prefixed by the SHA/author/date modified. You may want to make your window wider than normal to view this. If you have color support, the lines will be colored to show their age as well. Note, I've not tried this with a repo with as much history as Emacs. It's possible that it will run slowly there, I don't know. It may be possible to speed things up by disabling colorization etc. If you put point on a line and press "l" it will show you the Git commit message for that commit. "=" will show the complete diff of the commit. You can also move to the previous and next revision in the history. If, as above, you discover that the change you're looking at is not the one you want, you can use 'a' and it will jump to the commit before the one that made the change to the line point is on.