Ian Jackson <[email protected]> writes: > Control: reopen -1 > Control: retitle -1 Docs and messages about NEW/REJECT need overhaul > > Simon Josefsson writes ("Re: Bug#1127666: how to recover from > intermittent SSH push.dgit.d.o issue?"): >> Ian Jackson <[email protected]> writes: >> > Did you in fact rewind history to no longer include the REJECT-worthy >> > material ? >> >> No. Where is rewinding discussed? I see nothing relevant in dgit(1). > > Indeed, it's not discussed explicitly. It's implied by the option > name, but the option doesn't say *what* it's not fast forward from. > >> What do you actually mean by "rewind history"? Is that a >> well-established term for anything specific? > > Yes. Err. As an experienced git user you must surely be familiar > with this concept. You must know it by a different name. The kind of > thing that results in a force push.
Ah. I think this may partially explain why I haven't understood what --deliberately-* is about, and consequently have tried hard to avoid understanding them. If the documentation would explain what to actually DO in each of a carefully explained siatuion, maybe that helps people understand better. Right now I found the text theoretical and not practically relevant. > If the problematic package had legally dnagerous files, then we would > have to not ship them at all ever, even in git history on Salsa. So > you'd then need to filter them out (with git-filter-branch or > something maybe, or discarding upstream history entirely, or > something) and the you'd force push to all your Salsa branches. Maybe that manual already says that, but I think that explains the matter succintly in a way I didn't understand before. I'm trying to ignore that I think this may be a controversial take, or at least not clearly settled, and I think there are people who believe storing verbatim upstream code on Salsa is okay even when it doesn't pass DFSG tests. But it is fine for tools to support this way of working. Encouraging the workflow doesn't have to be dgit(1)'s job. > If you had done that, then you'd need to pass > --deliberately-not-fast-forward > to tell the dgit git server that yes, you are deliberately force > pushing. (Normally that's not even allowed by the server; but this > NEW/REJECT state is exceptional.) It's not clear to me what the difference compared to --deliberately-fresh-repo in practice would be. In what situation is that parameter applicable? >> > I assume that the REJECTed material is included in the history you're >> > publishing there ? >> >> Yes. The copyright REJECTs were because d/copyright had bugs, not >> because the content is undistributable. This seems like common >> scenario. > > Right. --deliberately-include-questionable-history is precisely > right, then. I think the current documentation in dgit(1) really doesn't say suggest that, but instead actually says to not use it: "only use this option after verifying that: none of the rejected-from-NEW ... versions in the git history of your current push, were rejected by ftpmaster for copyright ... reasons". That was what happened here. >> jas@frallan:~/dpkg/golang-filippo-nistec$ dgit push-built --new >> --deliberately-not-fast-forward >> -Cgolang-filippo-nistec_0.0.4-3_amd64.changes > ... >> History contains tainted commit 089445ef0355a294a39643e8f4d476fd88844fb5 >> Taint recorded at time 2026-02-11 00:43:10 Z for any package >> Reason: tag archive/debian/0.0.4-1 referred to this object in git >> tree but all previously pushed versions were found to have been >> removed from NEW (ie, rejected) (or never arrived) >> Could perhaps be forced using --deliberately-<something>. See dgit(1). > > This is expected. The system doesn't know that that commit wasn't > legally dangerous, and you haven't reassured it. I did pass --deliberately-not-fast-forward, shouldn't that reassue it? Maybe I still don't understand. > I think this exchange demonstrates that our documentation (and perhaps > messages) need rather more work. I'm reopening this bug. > > Would you be willing to cast your eye over our revised docs/message > wording? Eg by Assigning you Review on Salsa ? Feel free -- I will try to read and comment, but given that I don't yet understand this it will be a rather weak review, but hopefully one that will be useful for you as a "novice user without dgit developer mindset" reaction. /Simon
signature.asc
Description: PGP signature
