On Sat, 24 Nov 2018, Richard Stallman wrote: > If it is acceptable to them _and_ it gives correct output in all cases > that can appear in glibc, then I say yes.
I think "in all cases" is not realistic; there are cases of structural changes where any description in terms of named entities will be a mess, and of code with peculiarities arising e.g. from the use of macros to generate function definitions that makes it hard to identify relevant entities and where humans aren't going to write the name in a consistent form in ChangeLog entries either. What you previously said in <https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html> was "reliably enough that errors are rare and not a problem". > The reason I feel a need to insist on the second part > is that people have proposed depending on some git commands > that do not give correct results in all cases. If you're using git log -L (as a command "for seaching for commits that affect a particular defun", as you noted to be relevant in <https://lists.gnu.org/archive/html/bug-standards/2018-11/msg00005.html>), it's more a matter that in some cases you may need to customize the command used (for example, look at the defun and write appropriate regular expressions for its start and end), rather than always being able to use the "-L :funcname:file" form. Or run multiple "git blame" commands, to find commits that changed a line before the last one that changed that line. Once you know what defun you're interested in, you should always be able to find appropriate commands that will be reliable at finding commits for that particular defun - it just won't be a single command that always does the right thing for every defun. -- Joseph S. Myers [email protected]
