On Saturday 10 December 2011, Jim Meyering wrote: > Stefano Lattarini wrote: > > On Saturday 10 December 2011, Jim Meyering wrote: > >> I have not taken the time to write a commit hook to warn me when > >> a git log fails to match the corresponding ChangeLog delta. > >> It doesn't seem worthwhile. > >> > > Absolutely agreed; especially because, as long as the ChangeLog > > is version-controlled, it can be fixed with later patches ... > > Sounds like you misunderstood. What I would like is a git commit hook > that verifies, given there are ChangeLog diffs, that they match the commit > log text. > No, I understood correctly; I just also pointed out that, even if an erroneous ChangeLog entry is committed (in particular, a ChangeLog entry that doesn't match the git commit message), it can easily be fixed with a later commit since ChangeLog is kept version-conatrolled.
> Since packages that I care about that also VC a ChangeLog file > are so few, it hasn't been enough of a problem to merit my writing > the script. > I understood that as well; and I stated that I think you are right acting this way. > Perhaps you didn't see this: > > A ChangeLog that is generated from gitlog-to-changelog may now be corrected: > > http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/28858 > Yes, I had seen that; in fact, without such a feature, I wouldn't have agreed to make Automake's ChangeLog automatically generated ;-) > ... > >> > This is inspired to commit v1.11-389-g6da46f3, with additional > >> > >> s/inspired to/inspired by/ > >> > > Ouch. But I have already pushed, so we can't change the git commit > > message without distrupting the history; this typo will have to > > live on. Annoying, but no biggie. > > Yes, I noticed that, and do know that public git log are essentially > immutable. > Oh, I was sure you knew; my explanation was more of a "JFTR". > That's why I made it so gitlog-to-changelog can now > generate a corrected ChangeLog. > [SNIP] Thanks, Stefano