[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we have gnulib-tool.py emit the same copyright header?
From: |
Bruno Haible |
Subject: |
Re: Can we have gnulib-tool.py emit the same copyright header? |
Date: |
Wed, 28 Feb 2024 12:00:21 +0100 |
Collin Funk wrote:
> > git log -n 1 ChangeLog | grep ^Date:
>
> Ah, I see what is happening.
>
> [collin@debian gnulib]$ git log -n 1
> commit 431d6a7615245e6b32d95b4b27aab5d3af65ad2b (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Bruno Haible <bruno@clisp.org>
> AuthorDate: Wed Feb 28 00:33:49 2024 +0100
> Commit: Bruno Haible <bruno@clisp.org>
> CommitDate: Wed Feb 28 00:33:49 2024 +0100
>
> isnan: Fix compilation error in C++ mode on OpenBSD 7.5-beta.
>
> Reported by Christian Weisgerber <naddy@mips.inka.de> in
> <https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00261.html>.
>
> * lib/math.in.h (GNULIB_NAMESPACE_LACKS_ISNAN): Define on all platforms
> with clang ≥ 14.
>
> So the grep ^Date fails. I don't remember changing this but in my git
> config it is caused by this [1]:
>
> [format]
> pretty = fuller
OK, so we need to make this piece of code more robust against various
git configurations.
> The regular gnulib-tool gives me this:
>
> [collin@debian gnulib]$ gnulib-tool --version
> gnulib-tool (GNU gnulib 2024-02-28 00:00:00) 0.1.7153-431d6
Here, the git configuration fooled gnulib-tool too. $date ended up
being empty, and GNU date interprets the empty strings as "today at 00:00:00".
Which was unintended, but it's a decent fallback behaviour worth porting to
the Python code.
> It seems that the 'git command-name --pretty=medium' existed before
> git version 1.
Good. Thanks for the investigation.
I'm committing these three patches, that fix the version output also in the
presence of
[log]
date = relative
[format]
pretty = fuller
2024-02-28 Bruno Haible <bruno@clisp.org>
gnulib-tool: Make --version output independent of git's configuration.
Reported by Collin Funk <collin.funk1@gmail.com> in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00268.html>.
* pygnulib/GLInfo.py (GLInfo.date): Pass --format and --date options, to
override the user's git configuration.
* gnulib-tool (func_version): Likewise. Also pass options '-n 1', to
speed up the operation.
2024-02-28 Bruno Haible <bruno@clisp.org>
gnulib-tool.py: Avoid exception when 'git log' output is unexpected.
* pygnulib/GLInfo.py (GLInfo.date): When the 'git log' output does not
contain a line with the expected 'Date:' pattern, pass the empty string
to GNU date.
2024-02-28 Bruno Haible <bruno@clisp.org>
gnulib-tool: Avoid references to functions that get defined later.
* gnulib-tool (func_fatal_error, func_warning, func_readlink): Move
before func_gnulib_dir.
0001-gnulib-tool-Avoid-references-to-functions-that-get-d.patch
Description: Text Data
0002-gnulib-tool.py-Avoid-exception-when-git-log-output-i.patch
Description: Text Data
0003-gnulib-tool-Make-version-output-independent-of-git-s.patch
Description: Text Data
- Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/27
- Re: Can we have gnulib-tool.py emit the same copyright header?, Bruno Haible, 2024/02/27
- Re: Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/27
- Re: Can we have gnulib-tool.py emit the same copyright header?, Bruno Haible, 2024/02/27
- Re: Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/27
- Re: Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/28
- Re: Can we have gnulib-tool.py emit the same copyright header?,
Bruno Haible <=
- Re: Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/28
- Re: Can we have gnulib-tool.py emit the same copyright header?, Bruno Haible, 2024/02/28
- Re: Can we have gnulib-tool.py emit the same copyright header?, Collin Funk, 2024/02/28
- Re: Can we have gnulib-tool.py emit the same copyright header?, Bruno Haible, 2024/02/28