From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id F1zQGQtCUmCeBwAAWB0awg (envelope-from ) for ; Wed, 17 Mar 2021 13:53:15 -0400 Received: by simark.ca (Postfix, from userid 112) id 5BEAF1EF78; Wed, 17 Mar 2021 13:53:15 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 074861E54D for ; Wed, 17 Mar 2021 13:53:15 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 20A60385483C; Wed, 17 Mar 2021 17:53:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20A60385483C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1616003594; bh=SAusDgLEGWyrfVR1CR8S50OQkizyhAB/e6TEcw8snBs=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=aUrlLE4KeCo5CJ8+/0OzHnatVF7XRPx/G8LgO1SiaxFetMCbEXcu1/HVkrhaz8x0X YWlQz0cGGYE0f8W2kaA3lKD52xG8fPZlxnC8KA08BwzIzUz31pc2ZmeFoiEFcBsLTY d+HkEaGX6Qny5LnLWbdJ76VvBr2RB72hSd0h0acw= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 19D6F385483C for ; Wed, 17 Mar 2021 17:53:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 19D6F385483C Received: from fencepost.gnu.org ([2001:470:142:3::e]:40398) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMaM3-0002UK-4c; Wed, 17 Mar 2021 13:53:11 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2398 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lMaM2-0005rF-Pg; Wed, 17 Mar 2021 13:53:10 -0400 Date: Wed, 17 Mar 2021 19:53:09 +0200 Message-Id: <83ft0td5ve.fsf@gnu.org> To: Luis Machado In-Reply-To: (message from Luis Machado on Wed, 17 Mar 2021 14:24:27 -0300) Subject: Re: sim: replacing ChangeLog files with online git logs References: <83ft0zjys1.fsf@gnu.org> <83lfarhwjq.fsf@gnu.org> <83eegjhuuq.fsf@gnu.org> <8335wyj461.fsf@gnu.org> <83tup9disi.fsf@gnu.org> <2012fb21-38f2-3d1c-62c8-52d94d19e243@linaro.org> <83pmzxdegd.fsf@gnu.org> <83o8fhddg3.fsf@gnu.org> <18f4f0e2-0a35-a6c5-1886-943f81f817fd@linaro.org> <83mtv1dbzr.fsf@gnu.org> <83im5pdao2.fsf@gnu.org> X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb Reply-To: Eli Zaretskii Cc: gdb@sourceware.org Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" > Cc: gdb@sourceware.org, Mike Frysinger > From: Luis Machado > Date: Wed, 17 Mar 2021 14:24:27 -0300 > > > Well, if that's what the majority here wants, then so be it. > > That's what we should assess. From chatting with other active GDB > developers, my feeling is that most of us want to drop the process of > having to write ChangeLog entries manually. But we tend to keep quiet > and carry on doing it. I didn't start this discussion, mind you. > > (The importance of having the list of modified symbols in the log is > > that then one doesn't need advanced Git commands to find out which > > changes modified a given function and why.) > > > > I understand the concern about git. I used to find git a bit too cryptic > too, but using it daily has made that better. > > Now git log/git blame shows very useful information when I'm looking for > specific changes from a commit, and I rarely need to go through > ChangeLogs other than to find commits that touched a particular > function/variable. IME "git log" and "git blame" have shortcomings when used for forensics, and having a ChangeLog-style list of changes helps overcome that in many important use cases. > >> I tried vcs-to-changelog, it gave horrible/useless results with our > >> codebase. This is not an option. > > > > Too bad. Maybe we should report this to the developer of the script, > > it could help fix those shortcomings in the future. > > > > Maybe. But looking into the future, parsing C++ to extract that kind of > information is really not trivial. So it may never work in a reasonable > way for GDB without some serious effort put into the script. We don't need it to do a perfect job, only a reasonable one. A 80% success is a very big step forward wrt not having the information at all.