On Mon, 29 Jan 2018, Richard Stallman wrote: > I have never used git blame; I tried hard to use Git and gave up after > painful screws. > > 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. It's a different approach from looking at lists of entities for each commit, but I think it's just as powerful in practice. [*] For the particular case of reindentation, you can just use "git blame -w" to ignore whitespace, but for other cases where you want to go back before the most recent change to a particular line, specifying a commit with git blame can be useful. -- Joseph S. Myers [email protected]
