From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el) Date: Tue, 2 Jan 2018 18:50:06 -0800 Organization: UCLA Computer Science Department Message-ID: <544c170f-99bd-c701-3063-c697296a30a6@cs.ucla.edu> References: <87bmj6dda0.fsf@linux-m68k.org> <87vahe911g.fsf@lifelogs.com> <87374id7jy.fsf@linux-m68k.org> <877ett8g7k.fsf@lifelogs.com> <87a7yn7tqp.fsf@lifelogs.com> <878te75xa1.fsf@lifelogs.com> <87ind6l2tt.fsf@lifelogs.com> <877etklvsa.fsf@lifelogs.com> <83y3m0pv8u.fsf@gnu.org> <86608msw0h.fsf@dod.no> <838tdiet25.fsf@gnu.org> <87y3li4vh7.fsf@telefonica.net> <87efnan46u.fsf@linux-m68k.org> <86wp12qtgo.fsf@dod.no> <83tvw6chqv.fsf@gnu.org> <86shbprix7.fsf_-_@dod.no> <83608kck4c.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1514947739 18018 195.159.176.226 (3 Jan 2018 02:48:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Jan 2018 02:48:59 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Cc: sb@dod.no, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 03 03:48:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWZ6s-0004Hw-EQ for ged-emacs-devel@m.gmane.org; Wed, 03 Jan 2018 03:48:54 +0100 Original-Received: from localhost ([::1]:36263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWZ8p-000465-Ro for ged-emacs-devel@m.gmane.org; Tue, 02 Jan 2018 21:50:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWZ8B-00045v-3M for emacs-devel@gnu.org; Tue, 02 Jan 2018 21:50:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eWZ8A-0001oj-5v for emacs-devel@gnu.org; Tue, 02 Jan 2018 21:50:15 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36158) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eWZ85-0001mW-Ld; Tue, 02 Jan 2018 21:50:09 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 39951161389; Tue, 2 Jan 2018 18:50:08 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 09f2xzAJPr4b; Tue, 2 Jan 2018 18:50:07 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5B53D1613C8; Tue, 2 Jan 2018 18:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NgnaXRlItVKg; Tue, 2 Jan 2018 18:50:07 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 30B43161389; Tue, 2 Jan 2018 18:50:07 -0800 (PST) In-Reply-To: <83608kck4c.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221542 Archived-At: Eli Zaretskii wrote: > If you are looking for a specific change in a specific function, then > ChangeLog style is exactly what you want. If you are looking for > something else, why would you look at the log messages at all, instead > of using VCS commands related to history and forensics? Because I am looking for *why* the code is the way it is, and ChangeLog e= ntries=20 that emphasize function names are typically not that helpful. For example, I'm currently working on a Coreutils patch so that "mv a b c= =20 d/e/f/g/" will traverse the directories in d/e/f/g/ just once instead of = three=20 times (once each for "a", "b", and "c"), thus reducing an O(N**2) to an O= (N)=20 algorithm. In writing this patch I needed to answer the question, "Why do= es=20 Coreutils currently insist on traversing d/e/f/g/ once for each source fi= le,=20 instead of just once for all the source files?" One cannot answer this qu= estion=20 from the text of Coreutils' ChangeLog entries, even though these entries = are=20 reasonably well-written using the approved GNU style. In contrast, the problem "I am looking for a specific change in a specifi= c=20 function" is not a big deal, as it is so easily addressed by "git blame" = etc.=20 that it's not worth the maintenance hassle of writing and maintaining and= =20 reading commit messages that laboriously list every function that's affec= ted by=20 every patch. I'm not saying that commit messages should *never* mention file or functi= on=20 names; far from it. Just that our current style emphasizes them too much,= and=20 that we'd be better off spending our limited resources on commit messages= that=20 emphasize motivation instead of enumerating trivia. > . the first priority should be to leave the explanation as comments > in the code, if that is feasible, because then the commit explain= s > 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 of= ten=20 doesn't make sense. For example, when deleting a file one typically does = not=20 want to leave a message behind where the file used to be, saying "this fi= le was=20 deleted", as that would just slow down later maintainers who normally sho= uldn't=20 be burdened with the detritus of older versions. > . if the change was discussed in some public forum, include the > pointer to that discussion in the log message (bug number is a > special case of this, but it's not the only one) Very good advice.