bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using VC for change descriptions


From: Joseph Myers
Subject: Re: Using VC for change descriptions
Date: Mon, 29 Jan 2018 13:30:44 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]