gregor herrmann writes ("Re: [RFC] Proposal for new source format"): > On Thu, 31 Oct 2019 11:59:07 +0000, Ian Jackson wrote: > > * tag2upload service, or some related service: > > - determines that the maintainer is using a dgit-compatible git > > workflow, by looking at the tags, and looks at some in-dsc > > metadata to find the maintainer's repo > > - determines that the maintainer is using salsa or launchpad, > > converts the NMU to the maintainer branch's format, and > > submits an MR > > … after checking that the current state of the git repo corresponds > to the current version in the archive (which is often not the case in > my experience with NMUs) …
Right. This is one of the difficulties with the ad-hoc maintainer branches you find on salsa. And it is one of the ways that dgit helps. An NMU done with `dgit push-source', and starting from `dgit clone', always gets this right. But if the maintainer didn't use dgit to upload, `dgit clone' produces useless history, so the NMUer has to cope with lack of history; or if the NMUer wants history they can dig around in salsa. But if the NMUer fetches a branch from salsa it is not so easy to make sure that they start from the right git commit (and not possible to make a tool which gets it right every time). My enhanced scheme as I propose above could also get all this right. The NMUer would use `dgit clone' and they would see proper history because the maintainer had used tag2upload. So the NMUer's canonical-view git branch starts at the last upload, as it should. The tags specify where all the relevant versions are. So the converter can make a maintainer view branch starting at the maintainer's last upload. That's what would become the maintainer view MR. (It could be rebased if desired.) Ian.