On 25/02/2026 12:58, Bruno Haible wrote:
[Dropping autoconf list and setting a meaningful subject]
Zack Weinberg wrote:
git-version-gen is used by
several more projects besides Autoconf, and is officially maintained as
part of Gnulib, so I'm cc:ing both the autoconf mailing list and the
gnulib mailing list.
git-version-gen is a program that is meant to produce a single token.
In the case of a shallow git clone (and when no '.tarball-version' file
is present), it produces the token "UNKNOWN". This is as best as it can get.
The caller of this program may then print a warning if they want to.
But in fact, in some continuous integrations of some GNU packages, I've
found that "UNKNOWN" actually may work reasonably.
For now, let's maybe just make gitlog-to-changelog also print an
error message and quit.
In a shallow git clone, gitlog-to-changelog currently prints a ChangeLog
with just one entry. I would argue that is the desired outcome: a shallow
clone is indistinguishable from a checkout of a repository with just 1 commit.
I can imagine people wanting to run `make dist`
in a shallow clone in order to copy the tarball over to a machine that
doesn't have Git (yet) for testing purposes
Yes; I do this all the time in my continuous integrations. It works all
fine, even in shallow clones, except in packages that pass a specific
version range argument to gitlog-to-changelog (e.g. coreutils, inetutils)
or that verify the version in some unit tests (e.g. sed).
IMO, if something should be documented, it is that users who are
not interested in modifying a package (and looking at its history)
should better use the release tarballs from ftp.gnu.org, than a
git checkout. Basically:
- If user wants things to work out-of-the-box => Fetch release tarball.
- If user is not an expert with the package and not willing to become
an expert with the package => Fetch release tarball.
- If user wants to hack things like a developer => Fetch a git clone,
read the HACKING file, and don't complain if things don't work as
expected.
Bruno
[1]
https://www.gnu.org/software/gnulib/manual/html_node/gitlog_002dto_002dchangelog.html
I downloaded the git version of autoconf and tried to build it (running
into errors around shallow git clones) because I wished to test to see if
the bug I wished to report still existed in the development version, as it
was my impression that this was the polite thing to do (in order to avoid
false positives, and for example, what I believe GCC wants bug reporters
to do), and that doesn't seem to fall into any of your three use cases.
Though I suppose improving the documentation of HACKING is a potential
solution.
