Re: Preferred git branch structure when upstream moves from tarballs to git

[Ansgar <ansgar@debian.org>]

On Thu, 2019-05-09 at 10:33 +0100, Ian Campbell wrote:
> 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).

I think that is very confusing, yes.

By now I have come to understand that whatever "dgit" produces should
be just regarded as a build artifact, just like binary packages or for
some people the .dsc or for some workflows debian/patches/*.

Though directing users to build artifacts when they request the source
seems counterproductive to me...

I wonder why not the "maintainer view" is published (for the part
making Git repositories "reliably locatable") and any mangling is
applied by "dgit clone" (instead of "dgit push")?  ("dgit push" can
check that the mangling works.)

Then whatever is published is what is the actual preferred form of
modification (as it is what the maintainer uses), but if so desired one
can still get a "dgit view".  (Though for contributing changes to the
maintainer, one should probably base them on the maintainer view...)

In this case the published history also matches the "git histories we
are actually using ourselves", a design goal not met currently; one
could also apply the mangling feature to repositories not published on
the dgit server.

Ansgar