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, 14 May 2018 13:36:49 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Mon, 14 May 2018, Richard Stallman wrote:

>   > The good substitute is to use appropriate git workflows for the problem 
> at 
>   > hand.  For example, rather than mapping from commits to lists of changed 
>   > functions, looking at the changes in the function of interest (git log 
>   > -L),
> 
> We had a detailed discussion of this, and the result was that -L is
> mistaken about the changed entity's name in some cases.  As a

To be clear, while -L is based on the same logic as diff hunk headers 
(unless you use the fully general form where you specify arbitrary regular 
expressions), it's still more accurate than just taking a list of function 
names that appear in those headers (in the case where you want to know 
what commits changed a given function) - because a diff hunk header has to 
give a single name for a diff hunk, which is for the last function to 
start before that hunk, even if the function changed within the hunk also 
starts within that hunk, or multiple functions are changed, added or 
reordered within a single hunk.

Thus, -L has no problems with the case where the function changed starts 
within the hunk (or functions were reordered, etc.), which is one of the 
most common cases where looking at diff hunk headers would not give 
accurate lists of entities changed.  (There are still cases the default 
funcname regex doesn't handle, in particular #define - though it's also 
more subjective how you want to handle #define in this context; if the 
#define appears within a function, it certainly shouldn't be considered to 
terminate that function.)

*Once you know what entity you are looking for*, and what file it appears 
in, and have a copy of the repository, you can always use -L (in the 
/start-regex/,/end-regex/:file form if necessary, should the default 
funcname regex not suffice) to find the changes to it.

It's only if you want to look at the lists of entity names without already 
knowing which one you are interested in, or to find changes to an entity 
without having a copy of the repository, that an extracted list of entity 
names (based on some standard logic designed to handle all the common 
cases) becomes relevant.

-- 
Joseph S. Myers
address@hidden



reply via email to

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