Split Git
{{toc}}
Rationale
- Git becomes sluggish, mainly due to binary and source Debian packages we’ve been storing in Git.
- We’ve never taken advantage of mixing website with sources, so we only experience the disadvantages of it.
Our plan
New Git repositories
… with history imported and rewritten to filter out parts that were splitted out:
-
tails-live.git: the Tails source code we feed live-build with -
tails-website.git: the source of this website (i.e. more or less what is currently inwiki/src
APT repository
Current state: implemented.
We have imported binary and source packages from our Git repository for past releases (completed on 2012-11-14).
Let’s say the not-merged-yet branches will see their packages imported as they are worked on.
.mrconfig or Git submodules
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.
Additional custom repositories we use and may want to include in this
.mrconfig: whisperback, live-boot, live-config, vidalia, htp,
tails-greeter.
We probably should ship two mrconfig files: one that uses anonymous
git:// read-only remotes, the other that uses ssh:// read-write
remotes.
OTOH, 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.
Ressources:
Next things to do
Now that the APT repository (#5351 (closed)) is setup, and old packages imported, see sub-tickets for the next steps.
Subtasks
Related issues
- Related to #7036
Original created by @tails on 5506 (Redmine)