git, debian/<version> tags, dgit - namespace proposal [and 1 more messages]

Ian Jackson ijackson at chiark.greenend.org.uk
Mon Nov 16 13:27:33 UTC 2015


[resending because my MUA messed up]

Ben Hutchings writes ("Re: git, debian/<version> tags, dgit - namespace proposal"):
> Deliberately creating identifiers that differ only by case seems
> gratuitously confusing.

I acknowledge that this is a downside of my proposal.  However, it is
IMO important that the tag names I choose are relatively prominent.

A major part of the audience is people who don't know much about
Debian packaging, or even necessarily much about git workflows, let
alone about how Debian uses git.

If such a user sees two similarly named tags, they will at least know
that something is confusing.  They can look at the contents of each,
or type ignorant questions into a search engine, and hopefully find
the answer.  So the very obvious nature of the confusion is an
advantage.

If the user sees only the plain DEP-14 tag they are likely to use
that.  They will often then end up working with an unpatched tree.
Depending on the circumstances, they might not notice this mistake
until after hours of wasted effort, or at all.

  Further, it may cause difficulties for someone
> who is packaging for some other operating system and tries to clone a
> dgit repository onto a case-insensitive filesystem (which git generally
> does support).

This is indeed a problem.  Experiments (thanks to Tony Finch and Mark
Wooding) reveal that on MacOS and Windows `git clone' DTRT, we think
because it stores the refs in packed-refs.  But `git fetch' clobbers
one of the tags with the other.  I think this is a bug in git, and
maybe it will be fixed (especially if I report it) but it is a
problem.

Raphael Hertzog writes ("Re: git, debian/<version> tags, dgit - namespace proposal"):
> You should probably follow this with your own intermediate identifier,
> here are some ideas:
> - debian/patches-applied/<version>
> - debian/unpacked/<version> (referring to the fact that it's an unpacked
>   source package)
> - debian/source/<version> (same idea)
> - debian/raw/<version> (same idea)

Thanks for the suggestions.  I don't much like any of those; of them
/source/ is best but it's still rather misleading.  I'm open to
further ideas.

Colin Watson suggested (in pers.comm)
   pkg/debian/<version>
This is better but it still has a problem with collate order.

It may seem a petty thing to worry about, but for the reasons I
explain above I want something that sorts before `debian/<version>'.

Thanks,
Ian.



More information about the vcs-pkg-discuss mailing list