Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > diff --git a/Documentation/Makefile b/Documentation/Makefile > > index 2ccc3a9bc9..307634a94f 100644 > > --- a/Documentation/Makefile > > +++ b/Documentation/Makefile > > @@ -144,8 +144,6 @@ man5dir = $(mandir)/man5 > > man7dir = $(mandir)/man7 > > # DESTDIR = > > > > -GIT_DATE := $(shell git show --quiet --pretty='%as') > > - > > ASCIIDOC = asciidoc > > ASCIIDOC_EXTRA = > > ASCIIDOC_HTML = xhtml11 > > diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN > > index 9a1111af9b..14903bd261 100755 > > --- a/GIT-VERSION-GEN > > +++ b/GIT-VERSION-GEN > > @@ -10,7 +10,8 @@ LF=' > > # then try git-describe, then default. > > if test -f version > > then > > - VN=$(cat version) || VN="$DEF_VER" > > + VN=$(cut -d" " -f1 version) || VN="$DEF_VER" > > + DN=$(cut -d" " -f2 version) || DN="" > > Are we sure historical GIT_VERSION strings never had a SP in it? > I would be very surprised if we did, but the correctness of the > approach depends on that assumption. Why would that matter? Supposing a hypothetical tarball with a version '0.99 foo', it would have a corresponding GIT-VERSION-GEN (which didn't check for such file until 1.1.1), and it would know how to parse it. In other words: all three are tied together: the 'version' file, the GIT-VERSION-GEN script, and the tarball that has them both. -- Felipe Contreras
