Re: [PATCH] git-version-gen: detect untagged revisions

[Pádraig Brady]

On 14/04/15 19:43, Mats Erik Andersson wrote:
> Tuesday den 14 April 2015 klockan 11:40 skrev Pádraig Brady detta:
>> On 13/04/15 23:04, Mats Erik Andersson wrote:
>>> The addition of a leading 'g' to the revision hash is mostly a
>>> convenience, but the usability of the patched version applied
>>> to some cloned directory of small depth turned out more pleasant
>>> than I had expected.
>>
>> Pushed.
> 
> This has to be undone, as it breaks 'make dist' due to
> the incomplete (misbehaving?) file 'top/GNUMakefile'.
> There is no problem with a shallow clone, but a corner
> case exists with annotated tags.
> 
> The problem boils down to an issue of tag prefixes,
> namely as soon as it is not the default "v", presumed
> by git-version-gen.
> 
> GNU Inetutils prefers the tag prefix "inetutils-", so we
> use the preparator
> 
>    build_aux/git-version-gen .tarball-version 's/inetutils-/v/;s/_/./g'
> 
> This works correctly for the initial configuration and building,
> but the makefile target 'dist' will invoke 'top/GNUMakefile'
> and when computing '_curr-ver' in line 54, it executes
> 
>    $(_build-aux)/git-version-gen .tarball-version \
>        $(git-version-gen-tag-sed-script)
> 
> where this last sed script is empty. A recursive grep even for
> 'sed-script' gives single hit only, so no value is assigned.
> Hence this renewed call to git-version-gen is not performing
> any prefix masking, whence the tagged version will be rejected
> in the test
> 
>     #### build-aux/git-version-gen: line 161 -- 164
>     case $v in
>        $prefix[0-9]*) ;;
>        *) (exit 1) ;;
>     esac
> 
> since the default 'prefix="v"' is in use, where we would have
> needed "inetutils-".  Unfortunately, this is where my patch
> enters, because of the above "exit 1" my snippet becomes
> active and it prepends the character 'g' and is not able to
> remove the prefix "inetutils-", so is producing a hitherto
> unknown revision string and forces a new call to autoconf,
> where a simple tar-ball build would be expected.
> 
> It hurts to admit it, but the quickest and the best
> solution seems to be the reversal of my well ment patch.
> A whole lot of corner cases must be run through, due
> to unexpectedly large interplay, before one could depend
> on the result. It is the prefix handling and the sed script
> that cause these obscurities.

Done,

thanks for the analysis.
Pádraig