summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/Git_sub-repositories.mdwn
blob: a89c49c98c5de5b491365fe0bf543be9569aebc8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
**Corresponding ticket**: [[!tails_ticket 7036]]

# Goals

Tails is built from many sources: the main Git repository and our APT
repository (that includes binary packages built from other Git
repositories).

* See the "Diversions of bundled packages due to Tails point-releases"
  thread on tails-dev, in August and September 2013.
* Make it easier to determine what status of every sub-repo was used
  to build an existing ISO.
* Make it easier to decide what status of every sub-repo shall be used
  to build a new ISO.
* Simplify merging of topic and release branches: right now, we often
  have to merge things in two Git repositories (or more), and in the
  APT repository.
* Build most of our custom Debian packages at ISO build time, so that
  at least for those, the state of our APT repository doesn't matter.
* More continuous integration!

# Candidates

## mr

A few teams, such as the debian-installer and Debian Perl ones, that
use many Git repositories (thousands, in case of the latter), have
been successfully using mr to make an initial checkout easier for new
contributors, and generally making it easier to deal with a lot of
repositories (mass-update, etc.). We could do the same, starting with
maintaining and publishing a .mrconfig file. The problem with mr is
that it doesn't support branches out-of-the-box: checking out a branch
in the main repo doesn't do the same in sub-repos; *this* could be
automatized, but merging is another story.

Ressources:

* [d-i help page](http://wiki.debian.org/DebianInstaller/CheckOut)
* [pkg-perl help page](http://pkg-perl.alioth.debian.org/git.html)

## Git submodules

Git submodules allow to do basically the same thing, but also to make
it clear what version of these other repositories a given Git branch
(in the main repo) needs.

One problem with submodules is that the URL to every submodule's
repository is encoded in `.gitmodules`. So, either we encode read-only
URLs in there (and then, core developers need to use `pushInsteadOf`
or `insteadOf` in their Git configuration to rewrite these URLs
on-the-fly), or we encode read-write URLs in `.gitmodules` (and then,
non-core developers have to use `insteadOf`).

## Plenty of other solutions

When searching the web for well-known problems with Git submodules,
it's easy to find many other similar solutions or wrappers that are
meant to workaround these limitations.

* <http://ttboj.wordpress.com/2014/05/06/keeping-git-submodules-in-sync-with-your-branches/>
* <http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/>
* <http://somethingsinistral.net/blog/scaling-puppet-environment-deployment/>
* <http://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/>
* <http://www.mos6581.org/git_subtree_alternative>