maint: make inter-release --version output more useful

Now, each snapshot has a version "number" like 4.6-131-219-gda920ee,
which indicates that it is built using the 131st change set
(in _some_ repository) following the "v4.6" tag, and that da920ee
is a prefix of the commit SHA1.

* bootstrap.conf (gnulib_modules): Add git-version-gen.
* build-aux/.gitigore (/git-version-gen): Add entry.
* configure.ac: Run it to set the version from .tarball-version.
* Makefile.am (EXTRA_DIST): Add git-version-gen.
(dist-hook): Create .tarball-version in distribution tarballs,
never in a checked-out repository.
(AUTOMAKE_OPTIONS): Change from 'gnits' to 'gnu std-options readme-alpha'.
* .gitignore (.tarball-version): Add entry.
* doc/find-maint.texi (Making Releases): Adjust: tag before the build,
changed handling in NEWS, etc.
* NEWS (Changes to the build process): Document the change.

.gitignore

@@ -24,5 +24,6 @@ Makefile
 Makefile.in
 patches
 stamp-h1
+.tarball-version
 tests
 /tool-versions.txt

Makefile.am

@@ -15,13 +15,21 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
-AUTOMAKE_OPTIONS=gnits
-# readme-alpha
+AUTOMAKE_OPTIONS = gnu std-options readme-alpha
+
 AM_CFLAGS = $(WARN_CFLAGS)
 
-EXTRA_DIST = COPYING ChangeLog TODO config.h.in stamp-h.in \
-		THANKS \
-		tool-versions.txt README-hacking
+EXTRA_DIST = \
+	COPYING \
+	ChangeLog \
+	README-hacking \
+	THANKS \
+	TODO \
+	build-aux/git-version-gen \
+	config.h.in \
+	stamp-h.in \
+	tool-versions.txt
+
 DISTCLEANFILES = tool-versions.txt
 
 
@@ -41,8 +49,9 @@ tool-versions.txt: Makefile
 	runtest --version ; echo ; \
 	makeinfo --version ) > $@
 
-
+# Have .tarball-version based versions only in tarball builds.
 dist-hook: gen-ChangeLog findutils-check-pofiles findutils-check-testfiles
+	$(AM_V_GEN)echo $(VERSION) > $(distdir)/.tarball-version
 
 # gen-Changelog must still work when $(top_srcdir)/.git does not exist
 # because "make distcheck" verifies that you can "make dist" from the

NEWS

@@ -1,6 +1,6 @@
 GNU findutils NEWS - User visible changes.      -*- outline -*- (allout)
 
-* Major changes in release 4.7.0-git, YYYY-MM-DD
+* Major changes in release ?.?.?, YYYY-MM-DD
 
 ** Changes to locate / updatedb
 
@@ -113,6 +113,13 @@ Use --disable-silent-rules or "make V=1" to get verbose build output.
 xz is portable enough and in wide-enough use that distributing
 only .tar.xz files is enough.
 
+Maintainer builds from the Git repository now derive the version string from
+the version control system instead of using a fixed string (changed after each
+release manually).  As a result, the inter-release builds can now be
+distinguished: e.g. "4.6.0.152-fe9c" is the 152th commit after the tag "v4.6.0"
+and has the Git short hash "fe9c".  Builds from an unclean tree are marked with
+the suffix "-dirty".
+
 * Major changes in release 4.6.0, 2015-12-28
 
 ** Stable Release

bootstrap.conf

@@ -107,6 +107,7 @@ gnulib_modules="
     getopt-gnu
     gettext
     gettimeofday
+    git-version-gen
     gpl-3.0
     hash
     human

build-aux/.gitignore

@@ -25,3 +25,4 @@
 /warn-on-use.h
 /ylwrap
 /gendocs.sh
+/git-version-gen

configure.ac

@@ -19,7 +19,12 @@
 dnl Written by James Youngman.
 
 dnl Process this file with autoconf to produce a configure script.
-AC_INIT([GNU findutils], 4.7.0-git, [bug-findutils@gnu.org])
+# Make inter-release version strings look like, e.g., v4.6-131-gda920ee, which
+# indicates that it is built from the 131st delta (in _some_ repository)
+# following the v4.6 tag, and that da920ee is a prefix of the commit SHA1.
+AC_INIT([GNU findutils],
+        m4_esyscmd([build-aux/git-version-gen .tarball-version]),
+        [bug-findutils@gnu.org])
 
 dnl Set the bug-report URL
 dnl

doc/find-maint.texi

@@ -1069,14 +1069,14 @@ uncommitted changes.
 that the tests pass.  Verify this with @code{make distcheck}.
 @item Bugs; make sure all Savannah bug entries fixed in this release
 are fixed.
-@item NEWS; make sure that the NEWS and configure.in file are updated
-with the new release number (and checked in).
-@item Build the release tarball; do this with @code{make distcheck}.
-Copy the tarball somewhere safe.
+@item NEWS; make sure that the NEWS file is updated with the new release
+number (and checked in).
 @item Tag the release; findutils releases are tagged like this for
 example: v4.5.5.  Previously a different format was in use:
 FINDUTILS_4_3_8-1.  You can create a tag with the a command like this:
 @code{git tag -s -m "Findutils release v4.5.7" v4.5.7}.
+@item Build the release tarball; do this with @code{make distcheck}.
+Copy the tarball somewhere safe.
 @item Prepare the upload and upload it.
 @xref{Automated FTP Uploads, ,Automated FTP
 Uploads, maintain, Information for Maintainers of GNU Software},
@@ -1085,12 +1085,13 @@ for detailed upload instructions.
 file which explains what's changed.  Announcements for test releases
 should just go to @email{bug-findutils@@gnu.org}.  Announcements for
 stable releases should go to @email{info-gnu@@gnu.org} as well.
-@item Bump the release numbers in git; edit the @file{configure.in}
-and @file{NEWS} files to advance the release numbers.   For example,
-if you have just released @samp{4.6.2}, bump the release number to
-@samp{4.6.3-git}.  The point of the @samp{-git} suffix here is that a
-findutils binary built from git will bear a release number indicating
-it's not built from the ``official'' source release.
+@item Post-release administrativa: add a new dummy release header in NEWS:
+
+@code{* Major changes in release ?.?.?, YYYY-MM-DD}
+
+and update the @code{old_NEWS_hash} in @file{cfg.mk} with
+@code{make update-NEWS-hash}.
+Commit both changes.
 @item Close bugs; any bugs recorded on Savannah which were fixed in this
 release should now be marked as closed.   Update the @samp{Fixed
 Release} field of these bugs appropriately and make sure the