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]
41 \section{Why choosing \git}%{{{
43 \begin{frame}{It's a DSCM [1/2]}
44 I've packaged with SVN on svn.debian.org for a long time…
45 \uncover<2->{\alert{well, it sucks}:}
47 \item<3-> I wasn't able to work without network access;
48 \item<4-> I couldn't work incrementally: you have to get other's patches;
49 \item<5-> I couldn't "try and see" and maybe discard some work without
50 reverting patches: SVN never forgets;
51 \item<6-> I like having the full upstream source at hand, but svn explodes
52 doing that for large sources (KDE …).
56 \begin{frame}{It's a DSCM [2/2]}
57 With \git, as a DSCM, most of the issues are gone.
59 \item<2-> Off-line work is possible, in fact you always work off-line;
60 \item<3-> Incremental work is possible;
61 \item<4-> \git{} allow you to completely erase a wrong idea if you didn't
63 \item<5-> \git{} storage is extremely efficient: the marginal cost of
64 commits decreases with the number of commits.
70 GNU libc version 2.7 weights weights 115Mo unpacked. The full glibc
71 history (from before 1984) weights less than \alert{120Mo}.
77 My experience shows that \git{} storage, for a project with quite some
78 history, is smaller than 2.5 times the size of the last upstream release
83 \begin{frame}{A real maintainer toolbox}
84 Though \git{} is special, because it was designed by a {\bf Maintainer}.
85 This has several implications:
87 \item<2-> \git{} operations to look at the history are blazingly fast;
88 \item<3-> \git{} operations to integrate patches are blazingly fast;
89 \item<4-> \git{} supports advanced merging features;
90 \item<5-> \git{} has advanced patch manipulation features.
96 In other words, \git{} is a suitable replacement for both SVN and
97 quilt\footnote{or your preferred patch system}.
102 \section{Repository layout}%{{{
103 \begin{frame}{The repository layout: upstream}
104 First of all, my repositories contain upstream sources.
106 \item<2-> if upstream uses a public SVN or \git{} repository, I track
107 their SCM under the {\tt upstream/*} namespace.
108 \item<3-> if upstream tarballs differ from the SCM, I also add a
109 {\tt upstream/tarballs} branch that replicates the tarball
111 \item<4-> if upstream only releases tarballs, I only have an
112 {\tt upstream} branch that is the successive import of tarballs.
114 \item<5-> last and not least, {\tt pristine-tar} helps me saving the
115 pristine upstream tarballs inside git.
119 \begin{frame}{The repository layout: upstream}
121 {\bf Demo}: tokyocabinet packaging:
123 \item Step 1: importing upstream;
124 \item Step 2: backing up the orig.tar.gz.
128 \begin{frame}{The repository layout: patches}
129 Second of all, instead of using quilt, I use a private git branch to hold my
130 patch queue (usually called {\tt \$\{upstream\_branch\}+patches}). There are many
133 \item<2-> I only use one tool: \git{};
134 \item<3-> quilt doesn't know about diff3, unpractical for partially merged
136 \item<4-> I believe it to be nicer to browse or to cherry-pick for
141 {\bf Demo:} let's rebase our patch branch for tokyocabinet !
145 \begin{frame}{The repository layout: debian packaging}
146 Finally, everything that is Debian specific is kept into a debian branch.
148 \item<2-> One branch per suite: {\tt debian-etch}, {\tt debian-sid}, {\tt
150 \item<3-> the corresponding upstreams are merged into this {\tt debian}
152 \item<4-> the {\tt upstream+patches} branch is serialized under
153 {\tt debian/patches}.
157 {\bf Demo:} let's release our tokyocabinet package !
161 \section{How to turn mud into gold efficiently}%{{{
162 \begin{frame}{Hiding to the world you're a dirty pig}
163 There is nothing more useless than a crappy SCM history. I don't know how
164 {\it you} work, but I tend to do everything at the same time.
168 Well, then just bind {\tt :wa} to {\tt :wa<cr>:!git commit -a} in your
174 Then work like a pig, compulsively saving\^{}Wcommiting your stuff…
179 And when you're happy of the current sate, let's fake that you're a good
185 {\bf Demo}: the same in pictures.
188 \begin{frame}{Using \git{} for other's packages}
189 \git{} is not only useful as a versioning tool, it also helps to work fast
190 with NMUs and security uploads.
192 \item<2-> {\tt \$ git init \&\& git add .\@{} \&\& git commit -asm.}
193 \item<3-> {\it hack, hack …} {\tt \$ git commit -asm'try this'}
194 \item<4-> {\it hack, hack …} {\tt \$ git commit -asm'try that'}
195 \item<5-> {\it rebuild… Ok it works, let's produce a clean patch:}\\
196 {\tt \$ git rebase -i [...]}
201 Some packages don't rebuild twice in a row properly, because their
202 {\tt clean} target is broken…
206 \alert{I laugh at those}:\\
207 {\tt \$ git clean -d \&\& git reset --hard}
211 \section{The END !}%{{{
213 \begin{frame}{The END !}
214 If you're not too bored already, I'll gladly answer your questions now.
218 And remember, git has a tremendous community.
221 {\tt <mailto:git@vger.kernel.org>}
224 Also consult the documentation:
225 {\tt /usr/share/doc/git-doc/index.html}\footnote{I assume you have git-doc
226 installed, it will soon be part of base}.
230 % vim:tw=78 spell spelllang=en: