Re: RFD: please drop ChangeLog updates
Hello, Neil Jerram [EMAIL PROTECTED] writes: Actually, perhaps it would be nicer to put both those notes in a top level file called ChangeLog, rather than in HACKING. Yes, that's the most obvious place to put information about ChangeLogs. Other ChangeLogs can be renamed as you suggested. Finally, I'm assuming that there would be no change to the quality or style of the information that we used to put in ChangeLogs; the only difference is that the same information will now be in the commit message. Is that what everyone else is assuming too? Yes, that's my assumption, too, which is why I was looking for an Emacs mode to simplify the task. As far as releases are concerned, we can surely use one of these scripts to generate a top-level ChangeLog. It doesn't seem too complicated and may be handy for users who don't want to browse the Git repository. Thanks, Ludo'.
Re: RFD: please drop ChangeLog updates
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Ludovic Courtès escreveu: Then I guess I'm happy to abolish ChangeLogs. Two questions remain: 1. Should we remove ChangeLog files from the repo? 2. Should we generate ChangeLogs for releases? I'd say yes to (1) and no to (2). That would be a departure from the GNU Standards, but perhaps it's a sign of their age. I'd say no (1). The information in ChangeLog and commit message can diverge, so deleting them may remove information. I recommend keeping them around, Perhaps in a directory in with historic files, or marking them as THESE CHANGELOGS ARE NO LONGER UPDATED in screaming letters at the top. Oh right, I concur. Thanks, Ludo'.
Re: RFD: please drop ChangeLog updates
2008/8/30 Ludovic Courtès [EMAIL PROTECTED]: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Ludovic Courtès escreveu: Then I guess I'm happy to abolish ChangeLogs. Two questions remain: 1. Should we remove ChangeLog files from the repo? 2. Should we generate ChangeLogs for releases? I'd say yes to (1) and no to (2). That would be a departure from the GNU Standards, but perhaps it's a sign of their age. I'd say no (1). The information in ChangeLog and commit message can diverge, so deleting them may remove information. I recommend keeping them around, Perhaps in a directory in with historic files, or marking them as THESE CHANGELOGS ARE NO LONGER UPDATED in screaming letters at the top. Oh right, I concur. I agree on (1). We already have some historical ChangeLog files, like ChangeLog-scm and ChangeLog-1996-1999, and I suggest renaming the current set of ChangeLogs to ChangeLog-pre-git (or similar), and adding a note to HACKING about what that means. I'm less sure about (2), but I think I'd be happy with not generating release ChangeLogs, so long as we document (probably in HACKING again) how a ChangeLog since the previous release could be generated. Actually, perhaps it would be nicer to put both those notes in a top level file called ChangeLog, rather than in HACKING. Then anyone who looks for a ChangeLog will see the information they need, and also ChangeLog probably propagates into distribution packages more readily than HACKING would. (At least, it does for Debian.) Finally, I'm assuming that there would be no change to the quality or style of the information that we used to put in ChangeLogs; the only difference is that the same information will now be in the commit message. Is that what everyone else is assuming too? Regards, Neil
Re: RFD: please drop ChangeLog updates
[EMAIL PROTECTED] ha escrit: Guile is distributed as a tarball, not a git repo. Does it make sense to create the ChangeLog from the git log at make dist time? FWIW, there is a gnulib module for that purpose: gitlog-to-changelog. Once you import it to the project, the following Makefile rule will generate ChangeLog at make dist: dist-hook: if test -d .git; then \ $(top_srcdir)/build-aux/gitlog-to-changelog $(distdir)/ChangeLog; \ fi Regards, Sergey
Re: RFD: please drop ChangeLog updates
Ludovic Courtès escreveu: Hi, Sergey Poznyakoff [EMAIL PROTECTED] writes: [EMAIL PROTECTED] ha escrit: Guile is distributed as a tarball, not a git repo. Does it make sense to create the ChangeLog from the git log at make dist time? FWIW, there is a gnulib module for that purpose: gitlog-to-changelog. Emacs' VC (since 22.2) can also do that (see (info (emacs) Types of Log File)). That said, the ideal would be something like `add-change-log-entry' that operates on Git logs instead of ChangeLogs, but there doesn't seem to be anything like this. DVC is said to support things like that, but it doesn't seem to be well documented. Try magit (by Marius Vollmer, our previous overlord). It lets you create commits by marking individual patch hunks. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: RFD: please drop ChangeLog updates
Hi, On Fri 29 Aug 2008 12:56, [EMAIL PROTECTED] (Ludovic Courtès) writes: That said, the ideal would be something like `add-change-log-entry' that operates on Git logs instead of ChangeLogs, but there doesn't seem to be anything like this. DVC is said to support things like that, but it doesn't seem to be well documented. C-x V a I think. I wrote about DVC here: http://wingolog.org/archives/2008/03/11/using-newfangled-version-control-systems-from-emacs My work flow goes like this: * hack hack hack * M-x dvc-diff * j to go back and forth between file list and diffs * t to add a log entry * in the log entry, C-c C-c to commit * in the diff buffer, g to refresh That's about it, and works really well for me. Andy -- http://wingolog.org/
Re: RFD: please drop ChangeLog updates
Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Reasons: * Much more detailed and inherently correct information can be gotten from git log -- libguile/ git log -- test-suite/ etc. * The ChangeLog duplicates the git log information if done correctly. Hence it requires double work for the committer. Guile is distributed as a tarball, not a git repo. Does it make sense to create the ChangeLog from the git log at make dist time? -Dale
