From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4058 invoked by alias); 24 Jan 2012 19:40:25 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30121 Received: (qmail 22968 invoked from network); 24 Jan 2012 19:40:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120124114004.ZM30722@torch.brasslantern.com> Date: Tue, 24 Jan 2012 11:40:04 -0800 In-reply-to: <87r4yps14w.fsf@ft.bewatermyfriend.org> Comments: In reply to Frank Terbeck "ChangeLog generation (was: Re: Next release)" (Jan 24, 2:03pm) References: <20111209141117.52c1e37a@pwslap01u.europe.root.pri> <87iplpzfr0.fsf@ft.bewatermyfriend.org> <20111210171956.32b37a06@pws-pc.ntlworld.com> <877h24xmhh.fsf@ft.bewatermyfriend.org> <20111210194648.2ce77de2@pws-pc.ntlworld.com> <87r4yps14w.fsf@ft.bewatermyfriend.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: ChangeLog generation (was: Re: Next release) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 24, 2:03pm, Frank Terbeck wrote: } } Peter Stephenson wrote: } [...] } > I think when we can get to the point where I can type } > "Util/changelog.sh", or whatever, and recreate the ChangeLog } } I had some spare time, being on a train, and I came up with this: } } } } That should be good enough (minus bugs, obviously). Hrm. This is nice work and a pretty good compromise, but just in the course of looking through the sample output you included on that web page, there appear several cases where the existing ChangeLog is actually more accurate (thanks to having been repaired) than the commit log entries from which it would be "regenerated" by the script. One of my pet peeves with automating things in this way is that it often means typographical errors get enshrined for eternity, sometimes with confusing results when someone else goes looking through the logs. (Don't get me started on the inability to edit comments in bugzilla.) Also ... I'm not that familiar with how git organizes commits, i.e., what determines the list/of/change/files for a particular hash-sum. In an ideal world the commit entry for a given file would discuss only the changes relevant to that specific file, even if there were a bunch of changed files that should all be considered as a group in that the changes to one don't make sense without the changes to another. I have often found myself doing several "cvs commit" to cover each subset of the files that were edited, and then a single commit of ChangeLog with a composite description to give the context in which all the other commits were made. Is anything like that possible here? At the very least we're going to need to come up with a new convention for the commit logs so that the mailing list article IDs are not lost.