wiki/src/blueprint/Git_sub-repositories.mdwn

   1 **Corresponding ticket**: [[!tails_ticket 7036]]
   2
   3 # Goals
   4
   5 Tails is built from many sources: the main Git repository and our APT
   6 repository (that includes binary packages built from other Git
   7 repositories).
   8
   9 * See the "Diversions of bundled packages due to Tails point-releases"
  10   thread on tails-dev, in August and September 2013.
  11 * Make it easier to determine what status of every sub-repo was used
  12   to build an existing ISO.
  13 * Make it easier to decide what status of every sub-repo shall be used
  14   to build a new ISO.
  15 * Simplify merging of topic and release branches: right now, we often
  16   have to merge things in two Git repositories (or more), and in the
  17   APT repository.
  18 * Build most of our custom Debian packages at ISO build time, so that
  19   at least for those, the state of our APT repository doesn't matter.
  20 * More continuous integration!
  21
  22 # Candidates
  23
  24 ## mr
  25
  26 A few teams, such as the debian-installer and Debian Perl ones, that
  27 use many Git repositories (thousands, in case of the latter), have
  28 been successfully using mr to make an initial checkout easier for new
  29 contributors, and generally making it easier to deal with a lot of
  30 repositories (mass-update, etc.). We could do the same, starting with
  31 maintaining and publishing a .mrconfig file. The problem with mr is
  32 that it doesn't support branches out-of-the-box: checking out a branch
  33 in the main repo doesn't do the same in sub-repos; *this* could be
  34 automatized, but merging is another story.
  35
  36 Ressources:
  37
  38 * [d-i help page](http://wiki.debian.org/DebianInstaller/CheckOut)
  39 * [pkg-perl help page](http://pkg-perl.alioth.debian.org/git.html)
  40
  41 ## Git submodules
  42
  43 Git submodules allow to do basically the same thing, but also to make
  44 it clear what version of these other repositories a given Git branch
  45 (in the main repo) needs.
  46
  47 ## Plenty of other solutions
  48
  49 When searching the web for well-known problems with Git submodules,
  50 it's easy to find many other similar solutions or wrappers that are
  51 meant to workaround these limitations.