\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
-\usepackage{graphicx}
-
\usepackage{times}
%\usepackage[T1]{fontenc}
\newcommand{\git}{GIT}
\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;
\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}
\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.
{\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<cr>:!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 <mailto:git@vger.kernel.org>}
+ \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:
projects / ~madcoder / fosdem.git / blobdiff