> It's not that I like to commit "as fast" as possible, it's that I
> like to do fine-grained commits with tests at each step, so that if
> I screw up I can always revert to a known-good state without losing
> much work.
Yeah, git-style, as I've said before...
> The approach I have breen taking was predicated on the assumption
> that the ChangeLog entries would be read in conjunction with the CVS
> history -- so the latter says "what" and the ChangeLog says "why" at
> a slightly higher level.
Uhm, no. I've never seen it that way.
> While we're on the subject, though, I must say that I think
> traditional GNU-style Changelogs are obsolete and irritating. It's
> a convention that made a lot of sense before use of VCSes became
> common, but nowadays my Changelog is normally my VCS commit-message
> trail.
Just do the opposite (this is, use the ChangeLog entry for the CVS
commit message), and everything's fine.
> I'll update Changelogs (including groff's) because it's good
> citizenship -- but I really think they ought to be terminated with a
> note that explains how to pull the VCS audit trail.
I'll continue the current style (which is quite similar to, say,
`gnulib' or `emacs') as long as I'm using CVS for groff.
With git or hg, I completely agree that a traditional ChangeLog file
is no longer useful. However, in case you've downloaded a git
repository, you can check its complete history *offline* with `gitk'
or similar tools, something which you can't with CVS. This is the
very reason why I insist on precise ChangeLog entries.
Werner
