Package: dgit Version: 8.1 Severity: wishlist A condensed version of the following, or similar, should make it into the manpages. --overwrite is indeed causing confusion.
On Mon 29 Oct 2018 at 02:02PM GMT, Ian Jackson wrote: > The background to all of this is that --overwrite (without a version > number) is pretty safe: dgit will check that the version being > overwritten is mentioned in a not-UNRELEASED entry in your > debian/changelog. So you can only lose work from --overwrite in a > scenario which contains something isomorphic to this: > > (i) person P1 finalised the changelog with version V and a package > with contents V. Then they didn't actually upload for some > reason, but instead pushed the tree with the finalised changelog > somewhere (eg, salsa). So (calling that commit C1) salsa has: > commit history ...C1 > tree changelog ...V > tree contents V > > (ii) person PA takes that commit and makes more changes, and uploads > them, without noticing that they didn't need to finalise the > changelog, and without bumping the version. So (using `A' and > `CA' to refer to the the changes and commits made by PA) > now the archive contains > commit history ...C1-...-CA > tree changelog ...V > tree contents V+A > > (iii) person PB fetches from dgit (but not salsa), bumps the version > in the changelog from V to some higher version, wlog V+1. They > maybe make other changes. They now have > commit history ...C1-...-CB > tree changelog ...V;V+1 > tree contents V [+B] > Person PB now runs dgit push. dgit will notice that CB is not > fast forward from the archive (which has CA) and stop. > > But with --overwrite, dgit will examine the archive's version V > and see that PB's branch contains a finalised changelog entry for > V. dgit will conclude that CB contains all the changes in V, ie > all the changes in the archive. So dgit will make a pseudomerge > overwriting CA. The changes A made by PA in (ii) will be thrown > away. > > For this scenario to be realistic, PA != PB but maybe one of them is > the same as P1. This mistake scenario can be avoided by what might be > called `procedural controls': both P1 and PA have realistic options to > avoid the mistake. > > IMO P1 should burn the version number by bumping the changelog > version, after deciding not to upload but before pushing. IMO PA > should allocate a new version instead of adding changelog entries to > an already-finalised changelog entry. (Note that if P1 is foolish, > they might unfinalise the changelog after pushing, and then take on > the role of PA, avoiding that procedural control.) > > PB has an opportunity to see that something is wrong because hopefully > they will stop and think before simply passing --overwrite. If they > look at what is on salsa they will think all is well, but hopefully > they will look at what is in dgit/dgit/sid and notice the problem. > > Note that --overwrite=VERSION is much more dangerous. It does not > look at your own changelog at all. It simply trashes whatever was > in VERSION and replaces it with your upload. > > I notice persistent difficulties around when to use --overwrite. I > wonder if it needs a much longer discussion in one of the more > discursive manpages. -- Sean Whitton
signature.asc
Description: PGP signature
