Re: Preferred git branch structure when upstream moves from tarballs to git
Ansgar writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> On Thu, 2019-05-09 at 10:33 +0100, Ian Campbell wrote:
> > 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).
Everything Ian said is completely correct. Thanks, Ian :-).
> > 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/*.
As a maintainer you can think of it like, and treat it as, a build
product. The user or downstream can think of it like, and use it as,
the source code. It all depends on your point of view.
Fundamentally the circle being squared here is this:
* Maintainers think "the source code" means some Debian-specific
thing. Often a strange or dangerous thing - even the most usual, a
patches- unapplied git branch, is dangerous if you don't know how
to handle it. Furthermore the maintainers don't even agree.
* Users think "the source code" means a normal git branch you can
build and do `git grep' and `git commit' and `git merge' with.
Luckily it turns out that you can construct the 2nd from the 1st, in
most cases. (Indeed `gbp pq import' sort of does that and actually
for maintainers using gbp pq, the patch queue branch is the preferred
form for most *modifications* and the master branch is an interchange
format used for distribution; luckily the two are interconvertibel.)
And you can do it in such a way that the 2nd *contains* the 1st, so
that anyone who has the converted version also has the unconverted
version, if they care. In practice, it is IME very rare to want this.
> 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.)
dgit push makes, and publishes, a maintainer view tag, as well as a
dgit view tag. So you can indeed get the maintainer view.
So far no-one who is a user of `dgit clone' and `dgit fetch' has
requested a feature for presenting the maintainer view as a matter of
course. Such a feature would have some difficulties. What is the
`maintainer view' if the maintainer uses gbp pq, but the most recent
upload was an NMU not done with dgit ?
If you say "the .dsc import" then this "maintainer view" format
oscillates across versions. If you say "whatever you get when
converting the .dsc back to the maintainer's format" then a
backwards-converter would be required.
Or to put it another way, while everyone is required, when uploading,
to provide something that looks like a .dsc, not everyone who uploads
is required to provide something in some other maintainer-determined
format.
> Then whatever is published is what is the actual preferred form of
> modification (as it is what the maintainer uses),
The key question about "preferred form for modification" is "preferred
by who", of course. As I say above, maintainers and (at least a big
subset of) users/downstreams have different opinions.
Happily since the maintainer's view is always an ancestor of the
corresponding dgit view, publishing the dgit view implies publishing
the maintainer's view; and finding it in the history is
straightforward because there is an appropriate tag.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: