This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: Eric Wong <normalperson at yhbt dot net>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Petr Baudis <pasky at ucw dot cz>, Roland McGrath <roland at hack dot frob dot com>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Wed, 27 Mar 2013 02:48:59 +0000
- Subject: Re: ChangeLog entry complexity
- References: <20130311162425 dot DAD282C083 at topped-with-meat dot com> <20130311174341 dot GA28265 at domone dot kolej dot mff dot cuni dot cz> <20130311174940 dot 0E0512C08D at topped-with-meat dot com> <513E4924 dot 4010500 at redhat dot com> <20130311214322 dot GC31274 at machine dot or dot cz> <20130311214635 dot 5B9D32C08F at topped-with-meat dot com> <20130325164624 dot GA6137 at machine dot or dot cz> <51508192 dot 90702 at redhat dot com> <20130325205300 dot GA24293 at dcvr dot yhbt dot net> <Pine dot LNX dot 4 dot 64 dot 1303261741360 dot 8202 at digraph dot polyomino dot org dot uk>
"Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Mon, 25 Mar 2013, Eric Wong wrote:
>
> > As others have said, git is fast and powerful. There is no benefit to
> > reading a static ChangeLog when one can run git blame/log with the
> > appropriate options to get exactly what you need (and most importantly,
> > quickly filter out what one does not want).
>
> Given the messy state of the history converted from CVS (sometimes the
> heuristics to combine separate CVS commits to separate files into a single
> git commit helped, but sometimes they made things worse), in practice the
> ChangeLogs are often a better place to find all the history in one place
> (together with checking the old CVS repository in tricky cases).
Old history becomes less relevant over time. Old changelogs will
always be available if needed.
> > ChangeLog entries also lead to needing extra tools like
> > git-merge-changelog instead of just doing a plain cherry-pick/am.
>
> Not having a checked-in ChangeLog leads to on-the-side extra files with
> corrections to bad log messages and author information, information about
> multiple authors where git can only show one, etc. (see
> gitlog-to-changelog --amend). (I think in principle things such as log
> messages should themselves be versioned objects so you could refer to the
> state of the tree as of a particular commit, which would refer not just to
> the files in the tree and the history of the tree but to the state of the
> log messages etc. in that history. But I don't know of any version
> control systems that do that.)
git has a "notes" feature which allows supplementing commit messages.
I do not think it is very popular (or well known), but it is a standard
part of git for several years, now. I've never felt the need to use it
myself, though.