[Top][All Lists]

[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: Wed, 9 May 2018 12:37:37 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Wed, 9 May 2018, Richard Stallman wrote:

> What I recall is that git provides commands to get some information,
> but not the same information.

It's not the same information because, when you are investigating bugs 
(for example) using git, the natural workflow is not "get the same 
information you would from a ChangeLog, then investigate the bug as if you 
were using a ChangeLog".  It's using different tools, such as "git blame", 
"git bisect", "git log", "git log -L", "git show", etc., some of which 
have no good analogues with ChangeLogs at all.  The ability of everyone to 
get a full copy of the development history and work locally with that 
gives much more power in development than having the current source code 
and a ChangeLog summary of the history, just as having the source code 
gives much more power than trying to fix a problem given only the binary.

> For instance, one git command would give the name of the last function
> header before the change, and in most cases that would be the name of
> the function that the change was in, but sometimes it would be
> different.  When considered in a rough way, it appears to be a good
> substitute, but that is not always so.

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), or at what commits resulted in the present state of lines in that 
function (git blame), or at the diffs for a particular commit of interest 
(git show).

As Paul said in 
tools such as "git blame" are much more useful than the entity lists in 
practice once you're used to using them.

> I think it should be feasible to write a program that would scan
> two versions, and their diff, and determine reliably what functions
> the change was in.  At least for certain known languages -- and people
> who want to use another language could add support for it.

As reliable as the lists in ChangeLogs are, quite likely (the cases where 
the functions are problematic to identify also tend to be cases where 
ChangeLogs are particularly unhelpful, because code is being rearranged in 
a way that doesn't simply relate to named entities at all).

I just don't think it actually helps the community to have such a program, 
or that people would want to use it.  For those packages where developers 
like workflows based on entity lists, I expect ChangeLog format to 
continue to be used, with people writing the ChangeLogs in whatever way 
they are used to without using such a program.  For those packages where 
developers are comfortable with the git-based workflows and don't find the 
entity lists useful, such a program wouldn't be used either.  And new 
contributors coming from outside are by now much more likely to be 
familiar with git-based workflows (git is pretty ubiquitous in both free 
and proprietary software development) than those based on ChangeLog lists 
of entities.

Joseph S. Myers

reply via email to

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