On Oct 29, 2013, at 4:09 AM, Jim Meyering <j...@meyering.net> wrote: > Hi Gary,
Hi Jim,
> I think your patch is based on an invalid premise:
> That somehow "git describe" is at fault.
> Actually, the diagnostic you reported suggests that your gnulib
> repository has no tag, which means your environment is the cause, not git.
> A full clone of gnulib always has at least the v0.0 tag that "git
> describe" uses.
Thanks for the description of the issue, which I hadn’t fully understood
until now — and you are quite right, certainly. The problem then lies with
bootstrap (both gnulib bootstrap, and my rewrite which borrows the submodule
clone code from the gnulib version), which by design does not perform a full
clone of gnulib into the gnulib submodule of the parent project.
It would be a shame to force a full clone of the entire history of
gnulib just so that maint.mk can get the correct release number. I see
a couple of alternatives:
i) add version tags to the tree every once in a while so that git
describe;
ii) find a new way of calculating a version number in maint.mk that
doesn’t require a full depth clone;
iii) change bootstrap to always perform a full depth gnulib clone.
Any others? We need to reach a consensus on a solution in any case.
> Please revert your change and instead fix your local repository.
> I find that the commit-count part of that "git describe" output is useful.
> Otherwise, it is much harder to compare two gnulib version indicators.
My patch implements (ii), albeit with arguably undesirable formatting.
Before reverting, I’d really like to see an alternative solution that
doesn’t require deleting and making full depth gnulib clones every time
I want to release a project with the maint.mk rules. If you disagree
strongly, please feel free to revert on my behalf.
Cheers,
—
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
