This is the mail archive of the libc-alpha@sourceware.org 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]

usefulness of changelog files


rather than hijack existing threads ...

am i the only one that finds no value in the dedicated ChangeLog files
?  other large projects (such as Linux) utilize only git to track
history and seem to have no problem here.

looking at the GNU's logic for ChangeLog files:
http://www.gnu.org/prep/standards/html_node/Change-Logs.html

it makes perfect sense in a centralized vcs environment such as cvs
where tracking down tree-wide changes is a semi-impossible task.  but
with git, these problems are largely non-existent.  it transparently
provides the critical pieces:
 - what changed (git log --stat)
 - who changed them (git log | grep Author)
 - why things were changed (git log)
 - easy to undo changes (git revert)

seems to me that the ChangeLog files are a pure anachronism now that
wastes developer cycles on churning out noise that no one cares about.
 when i want to track down the history of code, everything is at my
fingertips with git -- there's no need to ever dive into the ChangeLog
files.  this format is also not utilized outside of GNU projects, so
we end up explaining to people how to format things/etc..., and for
some, they just don't care so they don't bother following up.

you could make an argument for ChangeLog files in the release tarballs
as those don't contain the vcs tree (.git/), but many GNU projects now
have scripts to autogenerate those.  should be easy to extract and do
the same.
-mike


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