Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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