1 \documentclass[10pt]{beamer}%{{{
5 \setbeamercovered{transparent}
8 \usepackage[english]{babel}
9 \usepackage[utf8]{inputenc}
11 %\usepackage[T1]{fontenc}
12 \newcommand{\git}{GIT}
15 \title{Packaging with \git}
17 \author{Pierre Habouzit}
19 \institute{FOSDEM 2008 - Debian Room}
23 \AtBeginSubsection[] {
24 \begin{frame}<beamer>{Why choosing \git}
25 \tableofcontents[currentsection,currentsubsection]
39 \section{Why choosing \git}%{{{
41 \begin{frame}{Because SVN isn't good enough}
42 I've packaged with SVN on svn.debian.org for a long time…
43 \uncover<2->{\alert{well, it sucks}:}
45 \item<3-> I wasn't able to work without network access;
46 \item<4-> I couldn't work incrementally: you have to get other's patches;
47 \item<5-> I couldn't “try and see” and maybe discard some work without
48 reverting patches: SVN never forgets;
49 \item<6-> I like having the full upstream source at hand, but svn explodes
50 doing that for large sources (KDE …).
54 \begin{frame}{Because \git{} does what I need}
55 With \git, as a DSCM, most of the issues are gone.
57 \item<2-> Off-line work is possible, in fact you always work off-line;
58 \item<3-> Incremental work is possible;
59 \item<4-> \git{} allows you to completely erase a wrong idea if you didn't
61 \item<5-> \git{} storage is extremely efficient: the marginal cost of
62 commits decreases with the number of commits.
66 \begin{frame}{A bit more about \git{} storage}
67 \git{} storage is very efficient and optimized. Some numbers:
71 xorg-xserver.git, goes back to 2000, is \alert{20MB} big. The last
72 orig.tar.gz is 8MB big, more than 84MB unpacked.
77 dpkg.git, whole history since April 1996, generates a git pack of
78 \alert{15MB}. The last dpkg release is 17MB big unpacked.
83 GNU libc version 2.7 weights 115MB unpacked. The full glibc history
84 (starts in the eighties) generates a \git{} pack of \alert{104MB}.
89 Though, this won't probably be true for packages with a lot of binary
90 stuff in it, where delta compression is less likely to produce good
91 results (games data packages come to mind).
95 \begin{frame}{A real maintainer toolbox}
96 \git{} is special, because it was designed by a {\bf Maintainer}. This has
99 \item<2-> \git{} operations to look at the history are blazingly fast;
100 \item<3-> \git{} operations to integrate patches are blazingly fast;
101 \item<4-> \git{} supports advanced merging features;
102 \item<5-> \git{} has advanced patch manipulation features.
108 In other words, \git{} is a suitable replacement for both SVN and
109 quilt\footnote{or your preferred patch system}.
114 \section{Repository layout}%{{{
115 \begin{frame}{The repository layout: upstream}
116 First of all, my repositories contain upstream sources.
118 \item<2-> if upstream uses a public SVN or \git{} repository, I track
119 their SCM under the {\tt upstream/*} namespace.
120 \item<3-> if upstream tarballs differ from the SCM, I also add a
121 {\tt upstream/tarballs} branch that replicates the tarballs
123 \item<4-> if upstream only releases tarballs, I only have an
124 {\tt upstream} branch that is the successive import of tarballs.
126 \item<5-> last and not least, {\tt pristine-tar} helps me saving the
127 pristine upstream tarballs inside git.
131 \begin{frame}{The repository layout: upstream}
133 {\bf Demo}: tokyocabinet packaging:
135 \item Step 1: importing upstream;
136 \item Step 2: backing up the orig.tar.gz.
140 \begin{frame}{The repository layout: patches}
141 Second of all, instead of using quilt, I use a private git branch to hold my
142 patch queue (usually called {\tt \$\{upstream\_branch\}+patches}). There are many
145 \item<2-> I only use one tool: \git{};
146 \item<3-> quilt doesn't know about diff3, unpractical for partially merged
148 \item<4-> I believe it to be nicer to browse or to cherry-pick for
153 {\bf Demo:} let's rebase our patch branch for tokyocabinet!
157 \begin{frame}{The repository layout: debian packaging}
158 Finally, everything that is Debian specific is kept into a \texttt{debian}
161 \item<2-> One branch per suite: {\tt debian-etch}, {\tt debian-sid}, {\tt
163 \item<3-> the corresponding upstreams are merged into this {\tt debian}
165 \item<4-> the {\tt upstream+patches} branch is serialized under
166 {\tt debian/patches}.
170 {\bf Demo:} let's release our tokyocabinet package!
174 \section{How to turn mud into gold efficiently}%{{{
175 \begin{frame}{Hiding to the world you're a dirty pig}
176 There is nothing more useless than a crappy SCM history. I don't know how
177 {\it you} work, but I tend to do everything at the same time.
181 Well, then just bind {\tt :wa} to {\tt :wa<cr>:!git commit -a} in your
187 Then work like a pig, compulsively saving\^{}Wcommitting your stuff…
192 And when you're happy of the current state, let's pretend that you're a good
198 {\bf Demo}: the same in pictures.
201 \begin{frame}{Using \git{} for other's packages}
202 \git{} is not only useful as a versioning tool, it also helps to work fast
203 with NMUs and security uploads.
205 \item<2-> {\tt \$ git init \&\& git add .\@{} \&\& git commit -asm.}
206 \item<3-> {\it hack, hack …} {\tt \$ git commit -asm'try this'}
207 \item<4-> {\it hack, hack …} {\tt \$ git commit -asm'try that'}
208 \item<5-> {\it rebuild… Ok it works, let's produce a clean patch:}\\
209 {\tt \$ git rebase -i [...]}
214 Some packages don't rebuild twice in a row properly, because their
215 {\tt clean} target is broken…
219 \alert{I laugh at those}:\\
220 {\tt \$ git clean -d \&\& git reset --hard}
224 \section{The END!}%{{{
226 \begin{frame}{The END!}
227 If you're not too bored already, I'll gladly answer your questions now.
231 And remember, git has a tremendous community.
234 {\tt <mailto:git@vger.kernel.org>}
237 Also consult the documentation:
238 {\tt /usr/share/doc/git-doc/index.html}\footnote{I assume you have git-doc
239 installed, it will soon be part of base}.
243 % vim:tw=78 spell spelllang=en: