1 \documentclass[10pt]{beamer}%{{{
5 \setbeamercovered{transparent}
8 \usepackage[english]{babel}
9 \usepackage[utf8]{inputenc}
13 %\usepackage[T1]{fontenc}
14 \newcommand{\git}{GIT}
17 \title{Packaging with \git}
19 \author{Pierre Habouzit}
21 \institute{FOSDEM 2008 - Debian Room}
25 \AtBeginSubsection[] {
26 \begin{frame}<beamer>{Why choosing \git}
27 \tableofcontents[currentsection,currentsubsection]
37 \section{Why choosing \git}%{{{
39 \begin{frame}{It's a DSCM [1/2]}
40 I've packaged with SVN on svn.debian.org for a long time…
41 \uncover<2->{\alert{well, it sucks}:}
43 \item<3-> I wasn't able to work without network access;
44 \item<4-> I couldn't work incrementally: you have to get other's patches;
45 \item<5-> I couldn't "try and see" and maybe discard some work without
46 reverting patches: SVN never forgets;
47 \item<6-> I like having the full upstream source at hand, but svn explodes
48 doing that for large sources (KDE …).
52 \begin{frame}{It's a DSCM [2/2]}
53 With \git, as a DSCM, most of the issues are gone.
55 \item<2-> Offline work is possible, in fact you always work offline;
56 \item<3-> Incremental work is possible;
57 \item<4-> \git{} allow you to completely erase a wrong idea if you didn't
59 \item<5-> \git{} storage is extremely efficient: the marginal cost of
60 commits decreases with the number of commits.
66 GNU libc version 2.7 weights weights 115Mo unpacked. The full glibc
67 history (from before 1984) weights less than \alert{120Mo}.
73 My experience shows that \git{} storage, for a project with quite some
74 history, is smaller than 2.5 times the size of the last upstream release
79 \begin{frame}{A real maintainer toolbox}
80 Though \git{} is special, because it was designed by a {\bf Maintainer}.
81 This has several implications:
83 \item<2-> \git{} operations to look at the history are blazingly fast;
84 \item<3-> \git{} operations to integrate patches are blazingly fast;
85 \item<4-> \git{} supports advanced merging features;
86 \item<5-> \git{} has advanced patch manipulation features.
92 In other words, \git{} is a suitable replacement for both SVN and
93 quilt\footnote{or your prefered patch system}.
98 \section{Repository layout}%{{{
99 \begin{frame}{The repository layout: upstream}
100 First of all, my repositories contain upstream sources.
102 \item<2-> if upstream uses a public SVN or \git{} repository, I track
103 their SCM under the {\tt upstream/*} namespace.
104 \item<3-> if upstream tarballs differ from the SCM, I also add a
105 {\tt upstream/tarballs} branch that replicates the tarball
107 \item<4-> if upstream only releases tarballs, I only have an
108 {\tt upstream} branch that is the successive import of tarballs.
110 \item<5-> last and not least, {\tt pristine-tar} helps me saving the
111 pristine upstream tarballs inside git.
115 \begin{frame}{The repository layout: upstream}
117 {\bf Demo}: tokyocabinet packaging:
119 \item Step 1: importing upstream;
120 \item Step 2: backuping the orig.tar.gz.
124 \begin{frame}{The repository layout: patches}
125 Second of all, instead of using quilt, I use a private git branch to hold my
126 patch queue (usually called {\tt \$origbranch+patches}). There are many
129 \item<2-> I only use one tool: \git{};
130 \item<3-> quilt doesnt know about diff3, hence isn't very practical for
131 partially merged patches;