From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14914 invoked by alias); 5 Jun 2004 16:07:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14905 invoked from network); 5 Jun 2004 16:07:41 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sourceware.org with SMTP; 5 Jun 2004 16:07:41 -0000 Received: from zaretski (pns03-196-13.inter.net.il [80.230.196.13]) by aragorn.inter.net.il (MOS 3.4.6-GR) with ESMTP id DAH33976; Sat, 5 Jun 2004 19:04:11 +0300 (IDT) Date: Sat, 05 Jun 2004 16:07:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-Id: <2427-Sat05Jun2004190137+0300-eliz@gnu.org> CC: mec.gnu@mindspring.com, brobecker@gnat.com, hilfingr@gnat.com, gdb-patches@sources.redhat.com In-reply-to: <40C1CB8E.7080108@gnu.org> (message from Andrew Cagney on Sat, 05 Jun 2004 09:33:02 -0400) Subject: Re: [PATCH]: Updates to Ada sources, part 1 (longish) Reply-to: Eli Zaretskii References: <20040603051228.E269F4B104@berman.michael-chastain.com> <2914-Fri04Jun2004144147+0300-eliz@gnu.org> <40C0C01D.7080504@gnu.org> <9743-Sat05Jun2004130832+0300-eliz@gnu.org> <40C1CB8E.7080108@gnu.org> X-SW-Source: 2004-06/txt/msg00103.txt.bz2 > Date: Sat, 05 Jun 2004 09:33:02 -0400 > From: Andrew Cagney > > We've on a number of occasions seen large through to extreemly large > merges (HP comes to mind) and on each occason the contributor, > unprompted, ensure that a correct ChangeLog was included. I would even be happy if the contributor would do that when prompted (I prompted them to begin with, remember?). However, I'm not sure we should insist on this given the contributor's reluctance to do that, when prompted. It is IMHO enough to have the required information readily available in the distribution; a separate file will achieve just that. > We're talking an hour or perhaphs two How is this consistent with the fact that tree-SSA merge required a full day of work to prepare the log entries? > The way to do this is to ignore the history and just look at the final > diff. That will lose information. > A bit of sed'n'sort will in a matter of minutes give the functions > added/deleted bit, leaving just terse verbage of the other functions > changed. If it's too terse, it isn't worth the effort. What we need is a description of the changes as if they were done yesterday, not an opaque list of new, deleted, and changed functions.