I will soon push the following change, followed by another that will add
this line
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
near the top of gnulib-tool. That CDPATH-unsetting change is the accepted
approach to rendering "cd" sensible, i.e., making it emit nothing
to stdout. Thus, there is no need to redirect stdout for every single
use of the "cd" shell builtin.
Gary, I suggest that you avoid using shallow clones of gnulib. Surely
you have at least one full clone, and with that, you can reference that
clone from any subsequent bootstrap, thus avoiding the network/disk hit
of cloning from scratch.
Also, for subsequent commits, please follow our convention of adding
an entry in ChangeLog that is equivalent to your commit log (you forgot
that for the commit I am partially reverting).
From 233419c39c6d13d84439b95766328a238ffb6518 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Mon, 28 Oct 2013 15:25:25 -0700
Subject: [PATCH] maint.mk: restore functionality removed by recent change
Sunday's change, v0.0-8062-g6b24f60, may have appeared correct from
the context of a shallow-cloned gnulib repository: "git describe"
would fail in such a directory. However, that change made it so
the reported gnulib revision no longer includes the version number
or a commit count, even when run from a full clone.
* top/maint.mk (gnulib-version): Use the full "git describe"
output when possible, e.g., the form above, rather than the
abbreviated, no-tag, no-commit-count string, and fall back to
using a 10-byte hash, rather than the default minimal-length
hash prefix, since while the minimal-length one may be fine today,
it is likely not to be unique for very long.
---
ChangeLog | 15 +++++++++++++++
top/maint.mk | 3 ++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index cf868ae..6fca0c7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2013-10-28 Jim Meyering <meyer...@fb.com>
+
+ maint.mk: restore functionality removed by recent change...
+ Sunday's change, v0.0-8062-g6b24f60, may have appeared correct from
+ the context of a shallow-cloned gnulib repository: "git describe"
+ would fail in such a directory. However, that change made it so
+ the reported gnulib revision no longer includes the version number
+ or a commit count, even when run from a full clone.
+ * top/maint.mk (gnulib-version): Use the full "git describe"
+ output when possible, e.g., the form above, rather than the
+ abbreviated, no-tag, no-commit-count string, and fall back to
+ using a 10-byte hash, rather than the default minimal-length
+ hash prefix, since while the minimal-length one may be fine today,
+ it is likely not to be unique for very long.
+
2013-10-26 Jim Meyering <meyer...@fb.com>
maint.mk: fix "release" target to build _version
diff --git a/top/maint.mk b/top/maint.mk
index bf8f53a..8cb58f8 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1283,7 +1283,8 @@ vc-diff-check:
rel-files = $(DIST_ARCHIVES)
gnulib_dir ?= $(srcdir)/gnulib
-gnulib-version = $$(cd $(gnulib_dir) && git rev-parse --short HEAD)
+gnulib-version = $$(cd $(gnulib_dir) \
+ && { git describe || git rev-parse --short=10 HEAD; } )
bootstrap-tools ?= autoconf,automake,gnulib
# If it's not already specified, derive the GPG key ID from
--
1.8.4.1.559.gdb9bdfb
