Re: [RFC] Proposal for new source format
- To: gregor herrmann <gregoa@debian.org>
- Cc: debian-devel@lists.debian.org
- Subject: Re: [RFC] Proposal for new source format
- From: Ian Jackson <ijackson@chiark.greenend.org.uk>
- Date: Fri, 8 Nov 2019 16:29:31 +0000
- Message-id: <[🔎] 24005.38891.983972.151416@chiark.greenend.org.uk>
- In-reply-to: <20191031234542.GP7749@jadzia.comodo.priv.at>
- References: <b41c171c1eb83a91b044d954b4ef5aa35c1129ad.camel@stuart.id.au> <87lftcno3v.fsf@hope.eyrie.org> <20191023180715.cq5ntwilgt55khfc@basil.wdw> <87wocvjoft.fsf@hope.eyrie.org> <20191026232059.GA27571@mit.edu> <87pnij850j.fsf@hope.eyrie.org> <878sp6qfk5.fsf@iris.silentflame.com> <20191028203512.GA23676@alf.mars> <875zk5oqci.fsf@iris.silentflame.com> <23994.52363.132433.518189@chiark.greenend.org.uk> <20191031234542.GP7749@jadzia.comodo.priv.at>
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.
Reply to: