Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging repositories"): > As I explained in the earlier discussion with Henrique, there are more > things than just : and ~ which are perfectly legal in debian version > strings, but are illegal constructs in git refnames.
AFAICT[1], the exceptions are: * No leading `.' * No trailing `.' * No trailing `.lock' (wtf?) * No consecutive dots `..' I am not aware of any special handling of these cases by existing Debian tools. I think git-buildpackage and dgit and probably most other tools would simply construct a git-illegal tag name, and bomb out when they can't create the tag. I think existing version numbers which violate these rules are probably rare. We should IMO fix this by inventing a representation for these troublesome cases. The following characters in git ref names generated from Debian version numbers remain entirely unused and available AFAICT: ! = , Additionally we can use these if we are slightly careful: @ There are some obscure restrictions on `@' which aren't likely to affect us. I would suggest that we should do some simple replacement of troublesome `.' by (say) `!'. Eg in Perl: s/\.(?=$|-|\.|lock$)|^\./!/g; (We want to replace . preceding - so that don't end up with revisionful numbers being treated differently to the corresponding revisionless substrings.) Examples: foo..bar foo!.bar foo.-bar foo!-bar .foo !foo bar. bar! But, ultimately, this is a bikeshed issue. I think the authors of DEP-14 and/or the maintainers of git-buildpackage should decide. Guido, Raphael: please let us know what you decide. > To make this even more amusing, somewhere between git 1.7 (on squeeze) > and git 2.1, the rules for what were legal in git refs were tightened > (at least once) to exclude even more things. I don't know offhand if > this is likely to happen again at any stage. The differences are (things documented as permitted git ref names in 1.7 and documented as forbidden in 2.1.3): * Consecutive slashes * Whole ref name beginning or ending with a slash * Whole ref name being the single string `@' This seems like a documentation clarification, rather than an implementation change. I doubt very much that any such ref names would have worked with 1.7. > I'd also be a bit wary of changing existing tools to behave differently > (between different Debian releases that are still supported even) without > a very careful look at what might be affected if previous transformations > were no longer reproduced in the same way, or behaved differently depending > on exactly which chroot you ran them in. At the moment we have a number of tools which do things differently. The effect is that it is difficult to rely on the information you get from the various repos. Standardising this seems like an improvement. Ian. [1] http://git-scm.com/docs/git-check-ref-format -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21612.47640.506529.976...@chiark.greenend.org.uk