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: Sat, 14 Jul 2018 10:05:36 +0300 Message-ID: <83o9fab8lb.fsf@gnu.org> References: <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> <83in5lg4ol.fsf@gnu.org> <398050a2-2224-f0a8-279a-ae4924e219f7@gmail.com> <87tvp251xm.fsf@bernoul.li> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1531551859 5083 195.159.176.226 (14 Jul 2018 07:04:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jul 2018 07:04:19 +0000 (UTC) Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, npostavs@gmail.com, rms@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 14 09:04:14 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 1feEbG-0001CA-Kn for ged-emacs-devel@m.gmane.org; Sat, 14 Jul 2018 09:04:14 +0200 Original-Received: from localhost ([::1]:40380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feEdN-0004eJ-NJ for ged-emacs-devel@m.gmane.org; Sat, 14 Jul 2018 03:06:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feEck-0004e1-51 for emacs-devel@gnu.org; Sat, 14 Jul 2018 03:05:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1feEcf-0001Bs-Aj for emacs-devel@gnu.org; Sat, 14 Jul 2018 03:05:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feEcf-0001Bo-78; Sat, 14 Jul 2018 03:05:41 -0400 Original-Received: from [176.228.60.248] (port=2171 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1feEcX-0004n4-Pg; Sat, 14 Jul 2018 03:05:34 -0400 In-reply-to: <87tvp251xm.fsf@bernoul.li> (message from Jonas Bernoulli on Fri, 13 Jul 2018 15:13:41 -0500) 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:227388 Archived-At: > From: Jonas Bernoulli > Date: Fri, 13 Jul 2018 15:13:41 -0500 > Cc: Clément Pit-Claudel , > Richard Stallman , Emacs developers > > The functionality should be split like so: > > 1. Generate a list of all changed symbols. > 2. Format the list according to some preference. > 3. Insert the formatted list somewhere. Sounds reasonable, thanks. > Whether *Emacs* should ChangeLog files is a different discussion > (which I don't want to take part in) This has never been part of this discussion, because that ship has sailed more than 3 years ago, and I don't think it's coming back. > some projects (currently including Emacs) use ChangeLog files, > while other (possibly including Emacs in the future) put the list of > modified symbols into the commit message only. And regardless of where > the information is put, not every project uses the same format. Actually, Emacs stopped maintaining ChangeLog files in Apr 2015. We nowadays generate ChangeLog from the Git log as part of preparing a release tarball. The ChangeLog-like entries we've been discussing are those we put into the Git commit log messages. > >From a non-technical perspective the hard part is agreeing on what the > one and only correct way of recording this information is, which I think > we never be able to agree on. We (everyone using version control) also > don't have to. So lets keep those things separate. They are not entirely separate, though: my impression is that some of the friction uncovered in this and similar discussions is that people have difficulties integrating the technical part (i.e. generation of the log entries) into their workflows. So one way of making the friction lower is to make this integration easier by providing convenience features that cater to more workflows than we currently support. Thanks.