This is the mail archive of the
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <normalperson at yhbt dot net>, <carlos at redhat dot com>, <pasky at ucw dot cz>, <roland at hack dot frob dot com>, <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Wed, 27 Mar 2013 16:40:50 +0000
- Subject: Re: ChangeLog entry complexity
- References: <Pine dot LNX dot 4 dot 64 dot 1303261741360 dot 8202 at digraph dot polyomino dot org dot uk> <20130327024859 dot GA25013 at dcvr dot yhbt dot net> <Pine dot LNX dot 4 dot 64 dot 1303271427040 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 122444 dot 1693913000175389808 dot davem at davemloft dot net>
On Wed, 27 Mar 2013, David Miller wrote:
> 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."
Which happens to be exactly the right thing to make such searches most
useful, by making them find substantive changes to those files or
functions but not global mechanical ones, which is what's most likely to
> 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.
It has a big mess for older changes where the revision-combining
heuristics for the conversion from CVS didn't work well.
> > (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.
I see nothing in "man git-log" about logs for files matching a pattern
(actually, it doesn't seem to say what <path> means at all, or to
reference any other specification for <path> in any other of the very
large number of git manpages), let alone for logs based on functions
rather than files or for excluding global mechanical changes from such
Joseph S. Myers