From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17307 invoked by alias); 15 Jan 2014 12:12:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17288 invoked by uid 89); 15 Jan 2014 12:12:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 15 Jan 2014 12:12:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 976BC1166A9; Wed, 15 Jan 2014 07:12:54 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NwaquYWHtH2l; Wed, 15 Jan 2014 07:12:54 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2D6C91166A5; Wed, 15 Jan 2014 07:12:54 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2D596E0816; Wed, 15 Jan 2014 16:12:51 +0400 (RET) Date: Wed, 15 Jan 2014 12:12:00 -0000 From: Joel Brobecker To: binutils@sourceware.org, gdb-patches@sourceware.org Subject: small request regarding commits in binutils-gdb.git Message-ID: <20140115121251.GM4639@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-01/txt/msg00496.txt.bz2 Hello, Please forgive this message for all (most) of you who already know this, but I happen to notice a few commits here and there, where the revision log contains a copy/paste of the ChangeLog entry. This was a pretty typical and accepted practice when were using CVS. But, the convention with git tools is that the first line should be the subject of the commit, and this subject should be followed by an empty line before the rest of the revision log starts (if there is text afterwards). Below are examples of commit revision logs which follow that convention: > daily update or > PR symtab/16426 > > * dwarf2read.c (dwarf2_get_dwz_file): Call gdb_bfd_record_inclusion. > (try_open_dwop_file): Ditto. Here is one, however, that does not follow the convention: > PR gas/16434 > * config/tc-z80.c (wrong_match): Provide format string to > as_warn. In the example above, making the "PR gas/16434" by stripping the leading spaces, and adding an empty line after it would be sufficient. However, I'd like to take this opportunity to suggest a practice that some of us have started adopting on the GDB project, which is to make the revision log something close to the email we'd send to submit patch for including in binutils-gdb.git. It would look like this: > psymtab cleanup patch 3/3 > > This last patch removes "partial" from the names of > expand_partial_symbol_names and map_partial_symbol_filenames. > It also renames expand_partial_symbol_names to match the > struct quick_symbol_functions "method" that it wraps: > expand_symtabs_matching. > > This patch also adds two parameters to expand_symtabs_matching > so that it can fully wrap the underlying quick_symbol_functions method. > This makes it usable in more places. > I thought of having a cover function that still had the same > signature as the old expand_partial_symbol_names function, > but I couldn't think of a good name, and it wasn't clear it was > worth it anyway. > > gdb/ChangeLog: > > * symfile.h (expand_symtabs_matching): Renamed from > expand_partial_symbol_names. Update prototype. > (map_symbol_filenames): Renamed from map_partial_symbol_filenames. > * symfile.c (expand_symtabs_matching): Renamed from The upside is that it makes it easier for you to submit your patch, even if it submitted a long time after you actually wrote the patch. Just use "git send-email", and voila. For the rest of the community, using a meaningful subject, one that actually gives a hint at what it does, is something that I have found to be really helpful. For instance, "Provide format string to as_warn" can be more helpful when scanning through a list of commits than "PR gas/16434". I am also considering the idea of writing a small hook that would reject new commits introducing commits where the "empty line after subject" rule is not followed. Would that be an acceptable restriction? -- Joel