public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: small request regarding commits in binutils-gdb.git
Date: Wed, 15 Jan 2014 16:04:00 -0000	[thread overview]
Message-ID: <83mwix44gh.fsf@gnu.org> (raw)
In-Reply-To: <20140115121251.GM4639@adacore.com>

> Date: Wed, 15 Jan 2014 16:12:51 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> 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 text before the log entry is just a long way of saying the same
thing as the log entry, isn't it?  It repeats the info that is already
in the log entry.  Why does it make sense to repeat all that?

> 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?

No objections from me.

  parent reply	other threads:[~2014-01-15 16:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 12:12 Joel Brobecker
2014-01-15 15:28 ` Mike Frysinger
2014-01-15 15:51 ` Tom Tromey
2014-01-15 16:04 ` Eli Zaretskii [this message]
2014-01-15 16:25   ` Joel Brobecker
2014-01-15 16:57     ` Eli Zaretskii
2014-01-15 17:12       ` Mike Frysinger
2014-01-15 19:48         ` Fred Cooke
2014-01-15 20:02           ` Mike Frysinger
2014-01-15 20:38             ` Eli Zaretskii
2014-01-15 20:57               ` Mike Frysinger
2014-01-15 21:09                 ` Eli Zaretskii
2014-01-16  2:11                   ` Alan Modra
2014-01-16  2:17                   ` Joel Brobecker
2014-01-16  1:41             ` Fred Cooke
2014-01-16  2:41               ` Mike Frysinger
2014-01-15 16:50   ` Pedro Alves
2014-01-15 17:03     ` Tom Tromey
2014-01-15 18:07   ` Gary Benson
2014-01-16 11:41   ` Jose E. Marchesi
2014-01-15 19:31 ` Cary Coutant
2014-01-15 19:45   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83mwix44gh.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=binutils@sourceware.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).