Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As far as I can see from what you've said elsewhere, for source format
> 3.0 (quilt), you're aiming for the "patches applied and also serialized
> in debian/patches/" state (matching git-dpm I think?), whereas Kali ends
> up with the "patches serialized in debian/patches/ but not applied"
> state (matching gbp-pq).
That is a correct characterisation of dgit's view of history.
But dgit will also cope with "some patches applied and also serialised
but some further commits made to git but not serialised in
debian/patches".
> Is your current work-in-progress on teaching dgit better 3.0 (quilt)
> handling available anywhere? I'd be interested in trying out the new way
> while comparing the same package in different repository layouts.
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=shortlog;h=refs/heads/wip.rebasing
aka
git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git#wip.rebasing
But DO NOT USE THAT VERSION TO UPLOAD. It generates git trees that
existing dgits cannot cope with.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21610.38337.477993.49...@chiark.greenend.org.uk
