Re: Preferred git branch structure when upstream moves from tarballs to git
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.
Reply to: