On Thu, 2019-05-09 at 11:19 +1000, Ben Finney wrote: > What I remain unconvinced of is the worth of abandoning the clean > separation between an upstream source repository (whether Git repository > or not) and a VCS repository for Debian packaging (typically in Git).
I think there's a common misconception here which has cropped up several times in this thread. (NB: I've not used dgit in anger yet, but I hope what follows is correct). That misconception is that "dgit repo" == "maintainer's repo", which is not actually the case. As a maintainer you can (if you want) just use "dgit push" (instead of dput) while only caring about (and interacting with) the "maintainer's repo", never touching or looking at dgit's view of the world (apart from perhaps noticing and ignoring some `dgit/*` branches in your _local_ repo, I don't beleive you are required to push those to anywhere, including your maintainer repo). The "dgit repo" provides a view onto precisely what has been uploaded to the archive, no more no less. Where it can (i.e. where maintainers are using "dgit push" etc) it tries to stitch in the "maintainer's repo" (which I think is part #1 of where this misconception arises) as a subset but it doesn't follow that using dgit implies any constraint on the maintainer's repo (or at least that is the aim, AIUI there are some bugs and wrinkles which make this less than 100% true in reality, e.g. #908747) There is a caveat though (which I think is part #2 of the misconception) which is that dgit sometimes does need to understand tooling which maintainer's are using in the "maintainer's repo" (i.e. it needs to understand gbp pq and debrebase etc to work with repos maintained that way). But "dgit needs to understand the maintainer's repo" does not imply the inverse "the maintainer's repo must be shaped somehow by the use of dgit". In fact AIUI not having the use of dgit put constraints on how a maintainer structures their repo is an explicit design goal of dgit. It follows that there are some "maintainer's repo" layouts/strategies which dgit is not currently aware of and is therefore unable to cope with (and I beleive "packaging only repo" workflow is one of those). However AIUI from what Ian has said elsewhere that this is purely down to prioritisation and time, and given either big demand or adequate time this workflow will be supported by dgit. There is no philosophical objection (in dgit at least) to such workflows nor a desire to force (nor nudge) maintainers away from using whatever workflow they wish to. Ian.