From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support) Date: Wed, 11 Jul 2018 06:32:58 +0300 Message-ID: <83o9fefnv9.fsf@gnu.org> References: <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> <838t6jgl1k.fsf@gnu.org> <601m6cc6.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1531279899 17017 195.159.176.226 (11 Jul 2018 03:31:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 03:31:39 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 11 05:31:35 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 1fd5qp-0004KH-75 for ged-emacs-devel@m.gmane.org; Wed, 11 Jul 2018 05:31:35 +0200 Original-Received: from localhost ([::1]:51480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd5sw-0001xA-3B for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2018 23:33:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd5sI-0001wz-9O for emacs-devel@gnu.org; Tue, 10 Jul 2018 23:33:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fd5sE-0008Kj-6t for emacs-devel@gnu.org; Tue, 10 Jul 2018 23:33:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd5sE-0008Kf-3B; Tue, 10 Jul 2018 23:33:02 -0400 Original-Received: from [176.228.60.248] (port=4627 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fd5sD-0001Ke-IK; Tue, 10 Jul 2018 23:33:01 -0400 In-reply-to: <601m6cc6.fsf@lifelogs.com> (message from Ted Zlatanov on Tue, 10 Jul 2018 20:54:33 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:227239 Archived-At: > From: Ted Zlatanov > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Tue, 10 Jul 2018 20:54:33 +0000 > > >> Is there any chance of evolving the commit message formatting > >> requirements to lower the friction of making a commit and reduce > >> redundancy? > > EZ> IMO, what you'd like to have will actually _raise_ the friction > EZ> (i.e. will be harder to provide) for many contributors, according to > EZ> my experience of reviewing quite a few patches. > > I really don't think the current format is easy for anyone, especially > new developers. The format is produced mechanically by Emacs commands, so I don't see why suddenly the format is the issue. Maybe I interpret "format" not the way you meant it? > It's also essentially repeating the headers from the diff. 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). > Anecdotally, every time I want to make a larger commit with a lot of > items, it feels to me like paperwork for its own sake and takes up a > long time. It usually takes me a few seconds per change, so I don't see why you feel like that. > Here's one way to write it more concisely and make it more readable, I'm not sure we should try to be as concise as possible in this case. Why does the number of characters matter? With the current format, most of those characters are automatically generated by Emacs. > keeping in mind that the diff is part of the same log and is thus going > to be right below the explanation Not when a ChangeLog is generated from it and put in the tarball. > commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf > Author: Basil L. Contovounesios > Date: Mon Jul 9 18:46:33 2018 -0700 > > Adds and documents the new predicate function proper-list-p > > Factors out several one-off implementations of the same functionality. > For discussion, see emacs-devel thread starting at > https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html. > > Implementation suggested by Paul Eggert in > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html. Here are the problems with this method: . 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. . We lose information about the "several one-off implementations" where the changes were done. You assume this information can easily be gleaned by examining the diffs, but even if the diffs are readily available, that assumption is not really true IME: it sometimes takes a non-trivial effort. For example, determining the function or variable in which the change was made is not always easy, as the diff hunks don't always announce the right symbol, especially if a single hunk describes changes in several of them, or if the language of the source is not supported by Diff for these purposes. . With changes that touch a single function or a small number of them, your proposal will actually yield _longer_ logs, which goes against your intent. Worse, it will require contributors to sit down and think how to describe a simple change without repeating the diffs, something that at least some of them will find not so easy, being non-native English speakers.