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.
