This is the mail archive of the mailing list for the glibc 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: ChangeLog entry complexity

From: "Joseph S. Myers" <>
Date: Wed, 27 Mar 2013 14:31:37 +0000

> A key point is *in one place* - it's easy to grep the ChangeLogs for 
> references to a particular file name or function name.

This is bogus, we know for a fact that files and functions are left
out of certain changelog entries.

It has even been stated that this is exactly the thing to do, leave
files and function names out, for a tree wide ABI change ala "All
callers changed."

So what you're stating is really a non-argument.

In fact, this is an argument for getting rid of ChangeLog files
and using GIT repo searches instead, because unlike ChangeLog
entries the GIT repo has complete information.

> (I've no idea how to get git to show all changes to a file of a
> given name, anywhere in the source tree a file of that name may have
> appeared at any time in the past - or to files whose names matched a
> given pattern - or to functions anywhere in the source tree with a
> given name, or whose names matched a given pattern.  The sysdeps
> structure of glibc makes those natural things to do.  But supposing
> git does have a way to list such changes based on patterns in file
> or function names, the "in one place" issue still applies.)

The GIT repository is one place, and yes it can do all of the things
you describe and more.

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