This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: small request regarding commits in binutils-gdb.git


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]