Wookey writes ("Bug#973896: dgit: Document practical effects of --damp-run
writing tags"):
> Using --damp-run with push (to check it will work) writes the local
> tag for the current version, but does not update the server.
I wonder if it would be better to discourage using --damp-run, or
rather, to encourage people to just go ahead without it. dgit is
chock full of safety catches and checks and stuff precisely to try to
help its user avoid making messes.
I think people use --damp-run because they are scared that "something
will go wrong" and make a mess. But dgit very rarely makes any kind
of public mess of the kind that --damp-run would avoid. I'm not sure
I can remember an occasion when it has done (although I'm a bit
sozzled now so I can't be sure).
The thing you are documenting here is only one of --damp-run's rather
strange aspects. Eg it can fail when a plain dgit push would have
succeeded. It's mostly provided for debugging etc., not as a primary
tool for helping user confidence.
If we wanted a thing that helped build user confidence, maybe that
should be something else.
If someone has used --damp-run on a real package, I think it would be
better for them to burn the vwrsion number, than to pass a force
option. Eg., what if one of the unsigned tags escaped somewhere ?
Alternativley if we want to make --damp-run into a proper thing for
this use case, we should make it work properly: eg, we could have the
subsequent push notice that the tags were unsigned and decide to be
happy to replace them with signed tags provided they referred to the
same commits. And maybe fix the other issues with --damp-run. But
the latter might be hard; I would have to UTSL to check for them.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
