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, 27 Nov 2017 13:52:27 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Sun, 26 Nov 2017, Paul Eggert wrote:

> Richard Stallman wrote:
> 
> > there are git commands for asking which functions were
> > affected by a certain commit, and finding commits that affect a
> > certain function....  Are
> > there unusual cases they don't handle right?  For instance, do they
> > work for macro definitions in C?
> 
> 'git blame' and 'git diff' are line-oriented, and work equally well for macros
> vs functions vs other kinds of definitions. They're the commands I normally
> use (perhaps via front ends). I'm not sure which git commands you're referring
> to as being function-oriented.

It's "git log -L :<funcname>:<file>".  (But I very rarely use that, 
generally finding blame/annotate more useful.)

If there are particular cases where a developer wants the "git log -L" 
functionality but finds the default funcname regular expression 
unsuitable, and blame/annotate aren't sufficient, they can either use the 
other form of "git log -L" where arbitrary regular expressions specify the 
start and end of the region to generate logs for, or add appropriate 
configuration to .gitattributes and .git/config.

> Many GNU developers have already been doing that for years. For example, when
> developing I do not look at ChangeLog files in the GNU projects I help
> maintain, except for ancient history that predates use of Git or Bzr or CVS.
> So this experiment has already been done.

Indeed.  We know that in practice distributed VCS history is a suitable 
substitute for ChangeLog files, including (from experience with non-GNU 
projects) when that history is not in ChangeLog format.

It is also clear in practice that there are certain kinds of changes for 
which the ChangeLog format is poorly suited, because those changes cannot 
readily be described or understood in terms of separate descriptions of 
what they do to each individual named entity affected, or because 
describing in those terms results in a very long description that is 
excessively duplicative of the diffs themselves (which can be seen in the 
VCS history).  In such a case, a good, higher-level description of the 
changes is needed - but adding the ChangeLog-format descriptions of each 
fragment of the changes is extra work that does not provide any 
corresponding benefit.  This is why I think we should stop requiring use 
of ChangeLog format.  (The standards already allow automatic ChangeLog 
file generation from version control history; the issue is with the 
format.)

-- 
Joseph S. Myers
address@hidden



reply via email to

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