[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
- Re: Using VC for change descriptions, (continued)
- Re: Using VC for change descriptions, Joseph Myers, 2018/05/10
- Re: Using VC for change descriptions, Paul Smith, 2018/05/10
- Criteria for Acceptable Git to ChangeLog, John Darrington, 2018/05/12
- Re: Criteria for Acceptable Git to ChangeLog, Richard Stallman, 2018/05/12
- Re: Criteria for Acceptable Git to ChangeLog, John Darrington, 2018/05/15
- Re: Criteria for Acceptable Git to ChangeLog, Richard Stallman, 2018/05/15
- Re: Criteria for Acceptable Git to ChangeLog, John Darrington, 2018/05/16
- Re: Criteria for Acceptable Git to ChangeLog, Richard Stallman, 2018/05/16
- Re: Criteria for Acceptable Git to ChangeLog, John Darrington, 2018/05/17
- Re: Using VC for change descriptions, Richard Stallman, 2018/05/14
- Re: Using VC for change descriptions,
Joseph Myers <=