From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: merging the unicode-2 branch (was: Re: Selection-set editing without VC-dired) Date: Sat, 05 Jan 2008 01:33:20 -0800 Message-ID: <200801050933.m059XKsK013042@oogie-boogie.ics.uci.edu> References: <20071230142812.C8027CF80B9@golux.thyrsus.com> <85wsqww8ie.fsf@lola.goethe.zz> <200801031956.m03Ju5Al027134@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199525648 14619 80.91.229.12 (5 Jan 2008 09:34:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 09:34:08 +0000 (UTC) Cc: esr@golux.thyrsus.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 10:34:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JB5QA-0001Zu-EZ for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 10:34:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB5Pn-0006Zj-Nq for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 04:34:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB5Pf-0006YU-Lz for emacs-devel@gnu.org; Sat, 05 Jan 2008 04:33:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB5Pd-0006Wy-RS for emacs-devel@gnu.org; Sat, 05 Jan 2008 04:33:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB5Pd-0006Wd-12 for emacs-devel@gnu.org; Sat, 05 Jan 2008 04:33:53 -0500 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JB5PY-0004Af-Qx; Sat, 05 Jan 2008 04:33:49 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id m059XKsK013042; Sat, 5 Jan 2008 01:33:20 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Sat, 05 Jan 2008 00:54:18 -0500") Original-Lines: 64 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86124 Archived-At: Richard Stallman writes: > > Recent trends in VCS make the ChangeLog file more important. The > > reason I dropped my opposition to multi-file commits is that I > > realized that the info I used to get by looking at a CVS log, I could get > > from the ChangeLog file instead with a suitable selective visibility > > mode. > > Can we then proceed with the unicode-2 branch merging then? > > Sorry, I don't follow. I think there is a misunderstanding here. > > Splitting > the ChangeLog per file was what was blocking the merge. > > I think that is the misunderstanding. What I asked for was not > to "split" the ChangeLog file. It was to simplify it, > getting rid of unnecessary duplicate entries. For instance, > if we have > > (foobar): Change xyz. > > and on a previous date > > (foobar): New function. > > then we only need the latter. If foobar is a new function, being > installed now, then we only need the "new function" entry. Well, Handa-san didn't sound like he thought this would be a good idea. Here is what he replied to you: (3) RMS wrote: > The most important part of the massaging is to get rid of duplicate > entries. For instance suppose a function named foo is added and then > changed 10 times. There will be 11 change log entries for it, but we > we only need to keep one: "New function". Even for a new funciton, I want to know why some piece of code is in the current shape. I many times encountered such a case that I don't remember why I wrote some code as the current way. In such a case, I read changelogs and get a hint. So, I don't want to loose the current information. If you don't insist on having just one entry for changes of a non-new function, please apply that also to a new function. For instance, I want to keep all of these information. (insert_from_gap): Adjust intervals correctly. (insert_from_gap): Fix argument to offset_intervals. (insert_from_gap): Make it work even if PT != GTP. (insert_from_gap): Call record_insert. (insert_from_gap): New function. Then, for instance, I can know (or recall) that the function is intentionally coded to work in the PT != GTP case. And I also stated that given the experience with the work I've done for doing such ChangeLog rewriting for the multi-tty merge the amount of effort involved in doing this type of rewrite is non-trivial, it can be at least a full day of work. I have yet to see any benefit from all that effort.