From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: rename and clean unexec.c Date: Wed, 04 Aug 2010 12:40:44 -0400 Message-ID: References: <83hbjjcxex.fsf@gnu.org> <87sk33pdpf.fsf@telefonica.net> <83aapbcoqs.fsf@gnu.org> <838w4vc7gs.fsf@gnu.org> <834oficgpf.fsf@gnu.org> <8339v2c9ea.fsf@gnu.org> <83zkx9bhhm.fsf@gnu.org> <83vd7xb9l0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1280940102 14284 80.91.229.12 (4 Aug 2010 16:41:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Aug 2010 16:41:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 04 18:41:41 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ogh1b-0004ji-Ep for ged-emacs-devel@m.gmane.org; Wed, 04 Aug 2010 18:41:41 +0200 Original-Received: from localhost ([127.0.0.1]:43287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogh1T-00067w-1o for ged-emacs-devel@m.gmane.org; Wed, 04 Aug 2010 12:40:55 -0400 Original-Received: from [199.232.76.173] (port=53830 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogh1K-000654-P4 for emacs-devel@gnu.org; Wed, 04 Aug 2010 12:40:46 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ogh1I-0005AG-Ug for emacs-devel@gnu.org; Wed, 04 Aug 2010 12:40:46 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:51258) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ogh1I-0005AC-N4 for emacs-devel@gnu.org; Wed, 04 Aug 2010 12:40:44 -0400 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1Ogh1I-0007Xc-CJ; Wed, 04 Aug 2010 12:40:44 -0400 In-Reply-To: <83vd7xb9l0.fsf@gnu.org> (Eli Zaretskii's message of "Fri\, 30 Jul 2010 12\:30\:35 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:128250 Archived-At: Eli Zaretskii writes: >> Cc: emacs-devel@gnu.org >> From: Dan Nicolaescu >> Date: Fri, 30 Jul 2010 03:37:30 -0400 >> >> Eli Zaretskii writes: >> >> >> Cc: emacs-devel@gnu.org >> >> From: Dan Nicolaescu >> >> 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.