[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
<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
address@hidden
- Re: Using VC for change descriptions, Joseph Myers, 2018/05/08
- Re: Using VC for change descriptions, Richard Stallman, 2018/05/08
- 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