Control: forcemerge 849041 -1
Nikolaus Rath writes ("Bug#850469: dgit: Can't push: corrupted object"):
> remote: dgit-repos-server: reject: corrupted object
> 1bc3c1e2d353386487d7d8e7740ebd21f369b107 (missing metadata)
Unfortunately dgit 2.13 has a critical bug. It generates corrupted
commits. See my message to d-d-a:
https://lists.debian.org/debian-devel-announce/2017/01/msg00001.html
> Help would be appreciated :-).
>
> Is this version number really burned now, or can I still do an
> upload with dput?
It's worse than that. Your git history needs to be rewritten.
I will write in a moment with advice on what you should do about that.
In the meantime, you have three choices:
1. Wait for advice from me on how to rewrite your history
2. If the faulty merge commit 1bc3c1e2d353 is at the top of your
history and not buried in it, you can perhaps strip it off and try
dgit push again with dgit 2.14. You can use `git fsck --no-dangling'
to check if that's the only faulty commit.
3. Do a non-dgit upload.
In all of these cases I would recommend using a new version number.
Is there some reason why that's difficult ? Reasoning about what can
safely be restarted in this anomalous situation is going to be
nontrivial. If you choose one of the above options I can perhaps
think about it and advise.
Apologies for all the hassle.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
