All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH] doc: doc-diff: specify date
Date: Sun, 07 May 2023 20:08:37 -0600	[thread overview]
Message-ID: <645859a541f23_4e612944b@chronos.notmuch> (raw)
In-Reply-To: <xmqq8re3inn4.fsf@gitster.g>

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Otherwise comparing the output of commits with different dates generates
> > unnecessary diffs.
> >
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  Documentation/doc-diff | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Ahh, it is a fix for a fallout from 28fde3a1 (doc: set actual
> revdate for manpages, 2023-04-13); when it is shown in the patch
> form like this, it is kind of obvious why we need to compensate for
> that change this way, but apparently "doc-diff" slipped everybody's
> mind back then when we were looking at the change.

Yes. doc-diff is an odd duck, because it can't be easily integrated to
the testing framework.

Sometimes a diff in the documentation is intentional, so the fact that
doc-diff generates an output from HEAD~ to HEAD is precisely what was
intended. However, sometimes it's not. Maybe a flag inside the commit
message such as GitHub's `[no ci]` might help, but it's beyond me how
could that be cleanly integrated to continous integration machinery.

For now doc-diff is meant to be run manually, therefore it's expected
that some unexpeced diffs are inevitably going to slip by, and more
relevantly: issues in doc-diff itself are going to slip by.

> Looking at the patch text of 28fde3a1, we pass GIT_VERSION and
> GIT_DATE to AsciiDoc since that version.  We were already covering
> GIT_VERSION by hardcoded "omitted" string, and now we compensate for
> the other one here, which means this change and the other changes
> complement each other, and there shouldn't be a need to further
> adjustment for that change around this area.  Looking good.

Yes. I think we should be passing a semi-real version instead, like
`0.0.0`, just to see how a real version would look like, but that's
orthogonal.

> > diff --git a/Documentation/doc-diff b/Documentation/doc-diff
> > index 1694300e50..554a78a12d 100755
> > --- a/Documentation/doc-diff
> > +++ b/Documentation/doc-diff
> > @@ -153,6 +153,7 @@ render_tree () {
> >  		make -j$parallel -C "$tmp/worktree" \
> >  			$makemanflags \
> >  			GIT_VERSION=omitted \
> > +			GIT_DATE=1970-01-01 \
> >  			SOURCE_DATE_EPOCH=0 \
> >  			DESTDIR="$tmp/installed/$dname+" \
> >  			install-man &&
> 
> I wonder what the existing SOURCE_DATE_EPOCH was trying to do there,
> though.

I also wondered the same, but again: orthogonal.

Cheers.

-- 
Felipe Contreras

      parent reply	other threads:[~2023-05-08  2:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 23:23 [PATCH] doc: doc-diff: specify date Felipe Contreras
2023-05-05  1:15 ` Junio C Hamano
2023-05-05  1:46   ` Jeff King
2023-05-05  5:55     ` Junio C Hamano
2023-05-05 21:16       ` Jeff King
2023-05-08  2:08   ` Felipe Contreras [this message]

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=645859a541f23_4e612944b@chronos.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.