Simon Josefsson writes ("Bug#1127666: how to recover from intermittent SSH
push.dgit.d.o issue?"):
> 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.
Hah. The real underlying mechanism has been ill-documented until now.
> 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.
Yes.
I have made an MR dgit!425 which just changes the documentation.
There is a big new section in dgit(7) with it.
It is not very easy to read the groff diffs on salsa. You can git
fetch the branch and stand in the dgit.git toplevel and say
make dgit.7.view
If that's awkward for you I can email you a diff of the
rendered-to-text form.
> 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.
Yes, I think you are right.
Storing non-DFSG material in upstream git branches on Salsa, and
formerly on Alioth, has been permitted for a very long time. We had
these conversations when moving from Alioth to the separate dgit git
server, and the conclusion was that that ship had sailed. (Rightly so
IMO.)
This conclusion needs to be stated clearly in official documentation.
> > 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?
When you're pushing to a distro that isn't Debian.
> 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.
Yes. This was overly cautious.
> > 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'm hoping the new docs I've written will help.
> > 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.
That is *precisely* the perspective I am looking for. A willing
guinea pig who is already confused by all this and knows they don't
understand it :-).
You can tell us if it answers your questions. Also, tell us if you
think a different structure would be better. The actual
operationalisable "awht do I do now" is at the end of the section,
both because this is the dgit(7) reference manual so it has a tendency
to go from overview, through cases, to specifics - and because in
certain circumstances we might want to alert the user if they *didn't*
rewrite the branch but should have done.
The MR is here
https://salsa.debian.org/dgit-team/dgit/-/merge_requests/425
Apparently I can't Request a Review from you because you're connected
enough to the dgit-team project. I've done a gitlab CC as well as
this email. I think you should be able to Start Review anyway;
if not please LMK.
Regards,
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.
