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 16:40:50 +0000

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

I'm sure a GIT wizard would be more than happy to teach you how to
data mine in exactly the way you want, but that's not what this
discussion is about.

I also don't think one can have it both ways.

On the one hand saying that the ChangeLog is the only place that
records all files and function names, so you can see when X or Y got
touched, and that this quality is essential and you cannot see how
GIT can do it.

And on the other hand saying that for tree wide ABI changes it's OK to
omit this information from the ChangeLog.  Either it's essential to
have complete information in the ChangeLog or it isn't.

I think that I could learn more from "git blame" on a single file in
the GLIBC repository than I could if I memorized every single
ChangeLog file we have in the tree.

Furthermore, complaining about the CVS conversion is a non-starter,
because we know that the ChangeLog entries from the pre-GIT era are
significantly incomplete, especially for the changes made by the most
prolific commiter at the time, Ulrich Drepper.

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