From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support) Date: Tue, 10 Jul 2018 23:53:21 -0400 Message-ID: References: <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> <838t6jgl1k.fsf@gnu.org> <601m6cc6.fsf@lifelogs.com> <83o9fefnv9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531281129 28925 195.159.176.226 (11 Jul 2018 03:52:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 03:52:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 11 05:52:05 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 1fd6Af-0007Qm-1O for ged-emacs-devel@m.gmane.org; Wed, 11 Jul 2018 05:52:05 +0200 Original-Received: from localhost ([::1]:51513 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd6Cm-0005oE-3I for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2018 23:54:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd6C5-0005nx-My for emacs-devel@gnu.org; Tue, 10 Jul 2018 23:53:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fd6C1-0007Pi-RR for emacs-devel@gnu.org; Tue, 10 Jul 2018 23:53:33 -0400 Original-Received: from [195.159.176.226] (port=51883 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fd6C1-0007PQ-JD for emacs-devel@gnu.org; Tue, 10 Jul 2018 23:53:29 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fd69r-0006aP-P4 for emacs-devel@gnu.org; Wed, 11 Jul 2018 05:51:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:khfNWp9beDTqqrQmh1sCxCGMNOA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:227241 Archived-At: > It summarizes diffs, in a way, yes (and allows to add explanations if > appropriate). I don't see that as a disadvantage: you don't always > have the ability to generate diffs (e.g., in a release tarball). FWIW, while I don't see the need to have such info when diffs aren't available, I do sometimes appreciate the summarizing part: it's easier to scan the commit message to see "oh there were 3 ad-hoc definitions of proper-list-p replaced by the new one" than to try and extract that info from the diff. Whether this occasional benefit is worth the effort, I don't know. > It usually takes me a few seconds per change, so I don't see why you > feel like that. It also takes me very little time, but our view is strongly biased here, since we're doing it so often that we got really good at it. For people who don't contribute often to Emacs (or other projects using a similar format) I'm sure it takes them significantly more time. > . How do you explain in CONTRIBUTE what should and what shouldn't be > in a log message? We have trouble getting contributors to follow > the current format; this one will leave us no levers to ask them to > do it correctly, I think. The same situation exists with comments, > but comments we can fix by followup commits, whereas log messages > are carved in stone once pushed. Agreed. Stefan