Jeff King <peff@xxxxxxxx> writes: > ... The reason is that asciidoc puts the <date> tags in the > header, and the custom header removed by 8806120de6c suppresses > asciidoc's default header entirely (so a workaround would be to include > the <date> tags in our custom header, but I don't see any reason not to > just build on top of 8806120de6c, as you did here). I agree building on what is in-flight instead of making duplicate effort makes sense. >> diff --git a/Documentation/Makefile b/Documentation/Makefile >> index 3133ea3182..b629176d7d 100644 >> --- a/Documentation/Makefile >> +++ b/Documentation/Makefile >> @@ -144,13 +144,16 @@ man5dir = $(mandir)/man5 >> man7dir = $(mandir)/man7 >> # DESTDIR = >> >> +GIT_DATE := $(shell git show --quiet --pretty='%as') > > What will/should this do in a distribution tarball, where we won't have > a Git repository at all? I think we'll just end up with a blank date in > the xml file, though it looks like docbook turns that into today's date > in the result. > > That's not _too_ bad, but feels a bit inconsistent (and it uses the > format you're trying to get rid of!). > > It would be nicer to populate the date variable in that case, like we do > for GIT_VERSION. I think that could look something like this: I did wonder the same "what about tarball" thing while reading this last night and then stopped, and it is good to see somebody else brought it up ;-). I like the "version" approach, as that is already an established way to deal with the same "the builder somehow wants to force the identifying string to a certain value in the build product". > 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. Thanks.
