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 <https://lists.gnu.org/archive/html/bug-standards/2018-01/msg00079.html>, 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 [email protected]
