- % autoconf && autoheader # or simply "make"
- % cvs commit config.h.in configure
- % make stamp-h.in # or simply "make"
- % cvs commit stamp-h.in
-
-The reason that the commits need to be split up is that the RCS Id strings
-in the files change when you commit, which can apparently mess up the
-dependencies. [How? -- Dan Harkless <dan-nmh@dilvish.speed.net> // CVS
-updates the strings to have the new version number, the modification time
-of the file gets updated by the OS. -- Kimmo Suominen <kim@tac.nyc.ny.us>]
-If this were not the case, you could commit with a single make followed by a
-cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in.
-[But since we have the RCS Id strings in the files, isn't it useless to even
-mention this? The fix would be to remove the strings, and I don't think that
-would be good. -- Kimmo Suominen <kim@tac.nyc.ny.us>]
-
-If you haven't changed all the files noted above, just commit the ones you have,
-in the stated order (for instance, configure.in, then configure, then
+ % autoheader; autoconf; \date > stamp-h.in
+ % cvs commit config.h.in configure stamp-h.in
+
+The reason for the three-step commit is that configure.in contains the RCS $Id
+keyword, so when you commit it, a new version is written locally. Therefore,
+the autoconf regeneration should be held off until after the commit, or your
+local stamp-h.in will become out-of-sync with the CVS version (granted, not that
+big a deal). For the second step, you're doing the same commands as a
+`make reset' would do, but using that command would require extra configure runs
+to make Makefile be up-to-date. The reason for the backslash on `date' is in
+case you have `date' aliased in your shell to use a nonstandard format.
+
+If you haven't changed all the files noted above, just commit the ones you have
+changed, in the stated order (for instance, configure.in, then configure and