Control: clone -1 -2
Control: retitle -2 git-debpush: detect and reject submodules
Control: clone -1 -3
Control: reassign -3 git-debrebase 12.12
Control: retitle -3 git-debrebase: submodules in upstream should be snags
Control: retitle -1 submodules and tag2upload, opportunities for improvement
Note:
I'm cloning this bug a couple of times for clearly defined
action items. Let us leave this original bug #1107219 for user
support, and discussion of further options.
Andrea Pappacoda writes ("Bug#1107219: git-debpush: upload failing when source
has submodules"):
> Yesterday I've finally given tag2upload a try with the cubeb package.
> It's wonderful!
I'm glad you're enjoying it :-).
> Still, I've encountered a surprising issue related to git submodules.
Sadly, git submodules are a complete disaster. I wrote a blog post
with a rant: https://diziet.dreamwidth.org/14666.html
But, I think our tooling could have served you better. Let me try to
give you some advice, and discuss possible improvement options.
> cubeb upstream uses git submodules, but they are not needed in Debian.
> In my tarball-based workflow, I've been able to ignore them, as the
> tarball generated by Git(Hub) creates empty directories where submodules
> should be. Fine.
Aha.
> When switching to git-debpush, I've also switched how I get upstream
> code. Since I package Git snapshot, I followed the instructions in
> dgit-maint-debrebase and now fetch the code from the upstream Git.
Yes, that is the workflow we would normally recommend. It is more
faithful and more traceable to upstream. Unfortunately the
faithfulness also exposes you to the submodules.
> With this change, though, submodules are now properly represented in the
> source. I still ignored them.
This is a reasonable thing for you to have attempted, even though it
was never going to work.
Our tooling ought to have detected this problem much sooner; and,
I think there are opportunities for making the workaround more
convenient.
> When pushing with git-debpush I then received an email with the
> following error:
tag2upload uses dgit to do a lot of the work, and this error is
basically #726953 "dgit fails with submodules".
> Ok, I just repacked the source removing the submodules with `git rm`,
> but I found this error kinda odd, especially as I had been able to build
> the package locally just fine.
I don't know your local building workflow, but many approaches for
local builds omit certain important consistency checks.
One of the key properties of our git transition tools, like tag2upload
and dgit, is that the source package (.dsc) is *completely identical*
to the (canonical) git view. That makes it possible to replace .dsc
with git without changing what source code you get, to convert in both
directions, and so on.
For a git submodule it's not quite clear what "identical" means here,
but it probably means the submodule is populated. This is discussed
at much greater length in another bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726953#64
> Is this expected? How am I supposed to deal with git submodules?
With our current tooling, I suggest treating the submodule the same
way we would treat nonfree materials. Ie, this part of the workflow
manpage:
https://manpages.debian.org/bookworm/dgit/dgit-maint-debrebase.7.en.html#DFSG-non-free:_When_upstream_tags_releases_in_git
It's not quite clear to me what you mean by "repacked". With
tag2upload you do not, in fact, ever need to have a terball on your
system. So you don't need to run git deborig.
As for our tooling and docs:
* git-debpush should definitely reject a submodule.
That would have detected the problem locally. (clone -2)
* git-debrebase should detect upstream trees that have
submodules and call that situation a snag. (clone -3)
* #726953 discusses more comprehensive submodule support
for dgit (which, if implemented, would extend to tag2upload too).
* Is there good tooling for doing DFSG-filtering entirely in git?
Eg is there some git tooling that will read uscan config?
* We need workflow manpages for tag2upload. Separately we want more
opinionated documentation of a git-first flow - that does not
involve gbp import-orig.
* I'm tempted to suggest an interim version of #726953 that makes it
possible to simply filter out submodules during canonicalisation.
That would improve convenience when upstream has submodules but the
Debian package wants to ignore all of them completely. How common
do we think this situation is?
(Note that it's easy to speak of doing this "as a quilt mode" or
"in quilt fixup" but it's not a "3.0 (quilt)" thing - it might
apply to native format source packages.)
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
