[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




Reply via email to