Hi, On Di, 2014-01-07 at 04:44 +1030, Ron wrote: > Hi, > > On Mon, Jan 06, 2014 at 12:08:51PM +0100, Benjamin Drung wrote: > > Package: gitpkg > > Version: 0.23 > > Severity: normal > > Tags: patch > > > > When a git repository has submodules, the content of the submodules won't be > > included in the source tarball. That's because git archive does not include > > the submodules. You need to call git archive for every submodules. A patch > > that does this is attached and tested with git repositories with and without > > submodules. > > This is definitely something I'd be interested in exploring more and > supporting > better if there's people who have real repos arranged this way. A few of us > have talked about it before, but the sticking point has mostly been that > nobody > has really found submodules to be a very sane way to do what they needed to > do, > so figuring out what the export tool ought to do without real examples of how > people were using them was putting the cart before the horse somewhat ... > > Can you point to some example of the repos you are doing this with?
We use submodules in a non-public git repository in the company. So I can't point you to it. This git repository contains the source code of the project including the debian directory. It has two submodules: One for the corresponding documentation and one for tests of a dependent project. The documentation has its own debian directory and can be build separately. You can easily create your own git repository with submodules. Just create two git repositories (or use just two random ones) and put one into the other. Here is just one example: git clone git://git.debian.org/git/users/ron/gitpkg.git cd gitpkg git submodule add git://anonscm.debian.org/collab-maint/distro-info.git distro-info git commit -m "Add random repository." gitpkg master > I have 2 initial comments on this patch ... > > - I suspect we'll want to make this optional in some manner, since it seems > plausible that there may be repos that have submodules to third party > projects that shouldn't actually end up in the export for that project > (since they may already be packaged separately in Debian). It may even > be the case that there are multiple submodules and _some_ belong in the > package being exported but not others. Hm. I wouldn't want to make exporting submodules optional if there is no need for it. There is no problem in shipping the source code of third party projects in your export, but building your package against the system version of these projects. Putting files into a tarball that you do not use just makes the tarball bigger. Not putting files into a tarball that you need let the build fail. > - I'm a little confused by this patch exporting submodules for the debian > tree only. In most cases that I tend to imagine, the submodules would > be part of the upstream source, not debian patches? Yes, you are right. I used create-fake-orig to create the orig tarball and there this code path is used. > So we probably need to do a bit more than just this to make it generally > useful, but I'm definitely interested in learning more about what repos > you've found submodules to actually be useful in, and how you're working > with them, so that we can ground the various theories in some actual > live practice but without tying people to only one possible configuration > (since I'm sure there are lots of ways people might combine separate repos > and I'm definitely sure there's more than I've so far imagined :). Here's our use case for gitpkg: We have different projects that are maintained in git. Most of these projects are Debian source packages and I know one package that use submodules. On every push, we generate a Debian source tarball with gitpkg (using the create-fake-orig option) and build the corresponding binary packages from it. Then we upload the binary packages into our own repository. We use gitpkg to just put everything of the git archive into a Debian source package (with the correct splitting of 3.0 quilt format sources). Cheers, Benjamin PS: Some developers dislike submodules as well and we may use subtree as alternative (or just in other projects). A test revealed that subtrees are already exported correctly with gitpkg. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
