On Fri, 30 Nov 2018, Alfred M. Szmidt wrote: > I was unable to follow the history of pr-menu-set-txt-title using git > log, git blame, or any other such command. Infact, I get the wrong > information from git blame, mainly because of things getting wrapped > with a eval-when: > > ebe4c71027c (Vinicius Jose Latorre 2007-10-27 00:25:43 +0000 1564) (defun > pr-menu-set-txt-title (value &optional item entry index) > > If we look at the ChangeLog, we learn that this function was infact > moved with in the file in 2008-02-01, and an alias was created for it
I think it's a feature for git blame not to show changes when a function was moved without its contents being changed, not a bug. If moves, reindentation, etc. confuse git blame, you can at least see what commit was shown in the git blame output and follow up with "git blame lisp/printing.el ebe4c71027c^" (repeat as needed for other such rearrangement commits showing in the history). It is considered good practice that a commit rearranging code should not at the same time make changes to that code, precisely because of the difficulty in seeing what those changes are when mixed up with a rearrangement, and if you follow that practice, repeating the "git blame" (or "git log -L", etc.) command with a series of different revisions named should work well. We could have such a policy - about making commits in a form that facilitates use of tools to examine the changes to particular entities - as something needed if not maintaining ChangeLog-format logs. (When I started this discussion in <https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html> I listed five conditions that seemed appropriate for not using ChangeLog format; this would be a sixth, although I don't think Paul Eggert's proposed patch to the standards necessarily incorporated all the proposed conditions.) -- Joseph S. Myers [email protected]
