Re: git history tracking across renames (and emacs support)

[Stephen Leake]

Paul Eggert <address@hidden> writes:

> Eli Zaretskii wrote:
>
>>    . the first priority should be to leave the explanation as comments
>>      in the code, if that is feasible, because then the commit explains
>>      itself, and the information is also available during simple code
>>      reading unrelated to VCS history searching;
> Yes, that is preferable if it makes sense in the new code. However, it
> often doesn't make sense. For example, when deleting a file one
> typically does not want to leave a message behind where the file used
> to be, saying "this file was deleted", as that would just slow down
> later maintainers who normally shouldn't be burdened with the detritus
> of older versions.

Yes, but for design decisions, it is useful to keep comments that say
"an alternative design ... was rejected because ..." so when some bright
newbie suggests the alternative, they are easily detered (or forced to
make it even better).

Sometimes these comments belong in the elisp manual.

-- 
-- Stephe