Re: rename and clean unexec.c

[Dan Nicolaescu <dann@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Fri, 30 Jul 2010 03:37:30 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Cc: emacs-devel@gnu.org
>> >> From: Dan Nicolaescu <dann@gnu.org>
>> >> Date: Thu, 29 Jul 2010 17:18:02 -0400
>> >> 
>> >> I am not sure why are so opposed to this.
>> >
>> > Not "so opposed", just opposed.  I'm opposed in principle to every
>> > cosmetic change that doesn't have a very good reason.  
>> 
>> Maintainability is a very good reason.   Keeping bad names is not.
>
> It should be obvious by now that we disagree on how much this
> particular renaming will contribute to better maintainability.

You might want to answer this question: how many people would change
and look at unexecoff.c?  
Based on the history of changes to that file the answer is zero.  Most
of the changes in many years have been to remove generic unexec
support for various other systems.
That means a bad name is a inconvenience to EVERYONE (a minor
inconvenience, but it's an inconvenience nevertheless)

>
>> > That's because
>> > such changes obscure real code changes and make forensics harder.
>> 
>> Can you please explain exactly how renaming a file managed by a decent
>> VCS makes forensics harder?
>
> I can only speak about Bazaar, as I'm not familiar enough with
> similar facilities of other dVCSs.
>
> The tools I use for forensics are:
>
>   . bzr log
>   . bzr diff
>   . bzr annotate

For these you would be much better off using C-x v [l=g].
It's MUCH quicker to look around and you can get access to one type
view when using another one.
IMO there's no reason to EVER use bzr annotate from the command line, C-x v g 
offers so many more very useful features.

>   . bzr bisect (and bzr revert in general)
>   . ChangeLog entries
>   . related discussions on emacs-devel and bug-gnu-emacs


> "bzr diff" and "bzr annotate" indeed support renaming nicely and
> transparently, but they are never enough to fully investigate the
> reasons for some change.  They just show what was changed and when,
> and who did that, so they are only the starting point.
>
> A minor gripe about "bzr bisect" and "bzr revert" is that they will
> move the renamed (or deleted) files to alternate names, which is fine,
> but requires one to be alert in order to prevent all kind of weird
> errors and warnings down the line.
>
> The rest of the tools I use have problems with renaming:
>
>   . The latter two need that you know about the renaming, or else you
>     won't hit relevant information in a search.
>   . The first one generally shows a slightly edited copy of a
>     ChangeLog entry, so it doesn't support renaming well, either; even
>     the entry for the rename itself will only mention the renaming if
>     the committer remembered to state that, i.e. it's prone to human
>     error.
>
> In addition, "bzr log" seems to have a bug that rears its ugly head
> with renamed files.  Observe:

Given that this is a bug in bzr tool, isn't it a bad idea to base
emacs file names policies on bugs in tools??

>   $ bzr log -c26091 --long src/s/usg5-4-common.h
>   bzr: ERROR: Path unknown at end or start of revision range: src/s/usg5-4-common.h
>
> (It works if I use usg5-4.h, the name it had when revno 26091 was
> committed.)

Again, if you use C-x v l, you can just use C-s to find revision
26091, and from there you can look at the diff, annotate and actual
file with a single key.