X-Git-Url: http://git.madism.org/?p=~madcoder%2Ffosdem.git;a=blobdiff_plain;f=git.tex;h=922e2bba194edebc245e68e1ced8a19e27c7b40d;hp=703730e951d1904134032d596186b31631049982;hb=HEAD;hpb=b801ce3a0f041554f1772f1d0dbb78047e7e37b9 diff --git a/git.tex b/git.tex index 703730e..922e2bb 100644 --- a/git.tex +++ b/git.tex @@ -7,8 +7,6 @@ \usepackage[english]{babel} \usepackage[utf8]{inputenc} -\usepackage{graphicx} - \usepackage{times} %\usepackage[T1]{fontenc} \newcommand{\git}{GIT} @@ -33,52 +31,70 @@ \begin{frame} \titlepage \end{frame} + +\begin{frame} + \tableofcontents +\end{frame} %}}} \section{Why choosing \git}%{{{ -\begin{frame}{It's a DSCM [1/2]} +\begin{frame}{Because SVN isn't good enough} I've packaged with SVN on svn.debian.org for a long time… \uncover<2->{\alert{well, it sucks}:} \begin{itemize} \item<3-> I wasn't able to work without network access; \item<4-> I couldn't work incrementally: you have to get other's patches; - \item<5-> I couldn't "try and see" and maybe discard some work without + \item<5-> I couldn't “try and see” and maybe discard some work without reverting patches: SVN never forgets; \item<6-> I like having the full upstream source at hand, but svn explodes doing that for large sources (KDE …). \end{itemize} \end{frame} -\begin{frame}{It's a DSCM [2/2]} +\begin{frame}{Because \git{} does what I need} With \git, as a DSCM, most of the issues are gone. \begin{itemize} - \item<2-> Offline work is possible, in fact you always work offline; + \item<2-> Off-line work is possible, in fact you always work off-line; \item<3-> Incremental work is possible; - \item<4-> \git{} allow you to completely erase a wrong idea if you didn't - shared it yet; + \item<4-> \git{} allows you to completely erase a wrong idea if you didn't + share it yet; \item<5-> \git{} storage is extremely efficient: the marginal cost of commits decreases with the number of commits. \end{itemize} +\end{frame} - \vspace{1ex} +\begin{frame}{A bit more about \git{} storage} + \git{} storage is very efficient and optimized. Some numbers: - \uncover<6->{ - GNU libc version 2.7 weights weights 115Mo unpacked. The full glibc - history (from before 1984) weights less than \alert{120Mo}. + \vspace{1em} + \uncover<2->{ + xorg-xserver.git, goes back to 2000, is \alert{20MB} big. The last + orig.tar.gz is 8MB big, more than 84MB unpacked. } - \vspace{1ex} + \vspace{1em} + \uncover<3->{ + dpkg.git, whole history since April 1996, generates a git pack of + \alert{15MB}. The last dpkg release is 17MB big unpacked. + } - \uncover<7->{ - My experience shows that \git{} storage, for a project with quite some - history, is smaller than 2.5 times the size of the last upstream release - (unpacked). + \vspace{1em} + \uncover<4->{ + GNU libc version 2.7 weights 115MB unpacked. The full glibc history + (starts in the eighties) generates a \git{} pack of \alert{104MB}. + } + + \vspace{1em} + \uncover<5->{ + Though, this won't probably be true for packages with a lot of binary + stuff in it, where delta compression is less likely to produce good + results (games data packages come to mind). } \end{frame} \begin{frame}{A real maintainer toolbox} - Though \git{} is special, because it was designed by a {\bf Maintainer}. - This has several implications: + \git{} is special, because it was designed by a {\bf Maintainer}. This has + several implications: \begin{itemize} \item<2-> \git{} operations to look at the history are blazingly fast; \item<3-> \git{} operations to integrate patches are blazingly fast; @@ -90,7 +106,7 @@ \uncover<6->{ In other words, \git{} is a suitable replacement for both SVN and - quilt\footnote{or your prefered patch system}. + quilt\footnote{or your preferred patch system}. } \end{frame} @@ -102,7 +118,7 @@ \item<2-> if upstream uses a public SVN or \git{} repository, I track their SCM under the {\tt upstream/*} namespace. \item<3-> if upstream tarballs differ from the SCM, I also add a - {\tt upstream/tarballs} branch that replicates the tarball + {\tt upstream/tarballs} branch that replicates the tarballs directly. \item<4-> if upstream only releases tarballs, I only have an {\tt upstream} branch that is the successive import of tarballs. @@ -117,22 +133,111 @@ {\bf Demo}: tokyocabinet packaging: \begin{itemize} \item Step 1: importing upstream; - \item Step 2: backuping the orig.tar.gz. + \item Step 2: backing up the orig.tar.gz. \end{itemize} \end{frame} \begin{frame}{The repository layout: patches} Second of all, instead of using quilt, I use a private git branch to hold my - patch queue (usually called {\tt \$origbranch+patches}). There are many + patch queue (usually called {\tt \$\{upstream\_branch\}+patches}). There are many reasons to that: \begin{itemize} \item<2-> I only use one tool: \git{}; - \item<3-> quilt doesnt know about diff3, hence isn't very practical for - partially merged patches; - \item - \item + \item<3-> quilt doesn't know about diff3, unpractical for partially merged + patches; + \item<4-> I believe it to be nicer to browse or to cherry-pick for + upstreams. \end{itemize} + \vspace{1ex} + \uncover<5->{ + {\bf Demo:} let's rebase our patch branch for tokyocabinet! + } +\end{frame} + +\begin{frame}{The repository layout: debian packaging} + Finally, everything that is Debian specific is kept into a \texttt{debian} + branch. + \begin{itemize} + \item<2-> One branch per suite: {\tt debian-etch}, {\tt debian-sid}, {\tt + debian-exp}; + \item<3-> the corresponding upstreams are merged into this {\tt debian} + branch; + \item<4-> the {\tt upstream+patches} branch is serialized under + {\tt debian/patches}. + \end{itemize} + \vspace{1ex} + \uncover<5->{ + {\bf Demo:} let's release our tokyocabinet package! + } +\end{frame} +%}}} +\section{How to turn mud into gold efficiently}%{{{ +\begin{frame}{Hiding to the world you're a dirty pig} + There is nothing more useless than a crappy SCM history. I don't know how + {\it you} work, but I tend to do everything at the same time. + + \vspace{1em} + \uncover<2->{ + Well, then just bind {\tt :wa} to {\tt :wa:!git commit -a} in your + editor… + } + + \vspace{1em} + \uncover<3->{ + Then work like a pig, compulsively saving\^{}Wcommitting your stuff… + } + + \vspace{1em} + \uncover<4->{ + And when you're happy of the current state, let's pretend that you're a good + boy. + } + + \vspace{1em} + \uncover<5->{ + {\bf Demo}: the same in pictures. + } +\end{frame} +\begin{frame}{Using \git{} for other's packages} + \git{} is not only useful as a versioning tool, it also helps to work fast + with NMUs and security uploads. + \begin{enumerate} + \item<2-> {\tt \$ git init \&\& git add .\@{} \&\& git commit -asm.} + \item<3-> {\it hack, hack …} {\tt \$ git commit -asm'try this'} + \item<4-> {\it hack, hack …} {\tt \$ git commit -asm'try that'} + \item<5-> {\it rebuild… Ok it works, let's produce a clean patch:}\\ + {\tt \$ git rebase -i [...]} + \end{enumerate} + + \vspace{1ex} + \uncover<6->{ + Some packages don't rebuild twice in a row properly, because their + {\tt clean} target is broken… + } + + \uncover<7->{ + \alert{I laugh at those}:\\ + {\tt \$ git clean -d \&\& git reset --hard} + } +\end{frame} +%}}} +\section{The END!}%{{{ + +\begin{frame}{The END!} + If you're not too bored already, I'll gladly answer your questions now. + + \vspace{2em} + + And remember, git has a tremendous community. + + \begin{center} + {\tt } + \end{center} + + Also consult the documentation: + {\tt /usr/share/doc/git-doc/index.html}\footnote{I assume you have git-doc + installed, it will soon be part of base}. \end{frame} %}}} \end{document} -% vim:tw=78: +% vim:tw=78 spell spelllang=en: