All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Felipe Contreras <felipe.contreras@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] doc: set actual revdate for manpages
Date: Fri, 14 Apr 2023 08:27:26 -0700	[thread overview]
Message-ID: <xmqq5y9yv601.fsf@gitster.g> (raw)
In-Reply-To: <20230414070449.GA540206@coredump.intra.peff.net> (Jeff King's message of "Fri, 14 Apr 2023 03:04:49 -0400")

Jeff King <peff@peff.net> 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.

  parent reply	other threads:[~2023-04-14 15:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13  7:47 [PATCH] doc: set actual revdate for manpages Felipe Contreras
2023-04-14  7:04 ` Jeff King
2023-04-14 12:40   ` Felipe Contreras
2023-04-14 16:46     ` Junio C Hamano
2023-04-14 17:14       ` Junio C Hamano
2023-04-14 18:40         ` Felipe Contreras
2023-04-14 18:26       ` Felipe Contreras
2023-04-14 21:45       ` Jeff King
2023-04-14 22:06         ` Junio C Hamano
2023-04-14 21:35     ` Jeff King
2023-04-14 15:27   ` Junio C Hamano [this message]
2023-04-14 16:20     ` Felipe Contreras
2023-04-14 17:36       ` Junio C Hamano
2023-04-14 18:59         ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq5y9yv601.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.