A git test drive

linux fan linuxscratch at gmail.com
Thu Oct 28 10:30:43 PDT 2010


I like git.
I'll share my curiosity in case anyone is curious about git.

I had feared it, thinking that it must be super-geeky and esoteric,
and thinking that it would give me severe stress headaches. But it
turns out to be quite the contrary of what I feared. It is suitable
for everyday use by ordinary people with ordinary computers who may or
may not wish to get on who's who lists so as to collaborate.
Collaboration is a possibility, not a requirement. Collaboration is
selective and there can be as many private work branches as desired,
such that any piece of work could be collaborated as is seen fit. At
least that is the impression that I get. A network is not even a

Git has built in change logging and diffs. It allows looking at the
whole picture from any temporal moment. It can replace my modus
operandi of making a "lastgood" copy of a file and then later doing a
diff to see what I had done.

My first motivation to try git, and my first use of it, was to do a
totally brain-free installation of xorg ... and it worked! However,
not really wanting to be on the bleeding edge, I rolled back and then
installed from 7.5 tarballs while using the same one-shot build.sh
procedure on xorg ModularDeveloperGuide, and that worked. I am
suspicious that if I knew the perfect moment of xorg, I could make a
private branch as of that commit, and then install.
A link to build.sh for non git persons (as I am/was)

The second thing I tried was to use git-svn to grab a copy of the blfs xml.
The entire blfs (all revs, all branches, didn't know any better) saved
in 204MiB in 2 hours.
The history going back to 6.2.0 saved in 17MiB in 30 minutes with
something like:
git svn clone URL -r 6635 blfs-xml
cd blfs-xml
git svn rebase
# Note: git svn rebase is approximately svn up
# Note: Without the -r N with clone, the rebase took hours.
# Not immediately obvious to me (a non svn-ist) was that the
# latest -r N can be seen on the blfs-book list (8650, or so).
# Note: This isn't an svn repository, it is a git repository that can
# interact with an svn repository, if desired, or git, if desired.

I lied!
It took way more time, because setting up to use git svn required some
extreme hoop jumping. It was not the performance of the setup that
took so long; it was following the paths of misdirection.
I. git-svn is not necessary unless one wants to try it.
II. git-svn wishes to find SVN::Core (aha, a perl module [right?])
III. Search leads to Alien-SVN (aha, that must be [isn't it?])
IV. Fails unless
     A. sqlite configured with --enable-threadsafe
     B. installed http://cblfs.cross-lfs.org/index.php/APR
     C. installed http://cblfs.cross-lfs.org/index.php/APR-util
     D. In lieu of B., C., you can (messy) unpack B. and C.
        in a specific place (wherever) within Alien-bla-bla
        but must make symlink apr to apr-unpacked-tardir
        and ditto for apr-util.
     E. Alien-bla-bla has less than zero documentation what
        you are supposed to do.
        1. Build.PL; ./build; ./build test; ./build install
        2. Maybe you didn't want some of that junk going into perl.
        3. It's older subversion libs.
V. Alien-SVN actually amounts to installing an old subversion with
    swig-pl into perl, but
    A. when I delete source directory failure due to
       1. some of libs linkered to source directory (deleted)
    B. Undo III., IV., and V.
VI. Subversion with swig-pl by the book is much easier than Alien-SVN.
   A. install http://cblfs.cross-lfs.org/index.php/SWIG
   B. Subversion has reasons that the perl module is not cpan ready.
VII. Now it is cooking.

Installation of git could go pretty much "by the book" in the INSTALL
file in the distribution, but I used some tweaks and got cleaner
install and cleaner man pages using the alternate method man pages
./configure --prefix=/usr \
            --without-curl \
            --without-tcltk \
            --sysconfdir=/etc \
            --libexecdir=/usr/lib/git \
make install
The --without-curl, --without-tcltk are obviously for when you don't have that.
Without --libexecdir=/usr/lib/git, it installs some stuff flat in /usr.

# While the man documentaion is extremely easy to find on the web as
needed, having the local man capability may be a nice convenience.
Especially since I don't know much about it. When I installed the
documentaion via make (install) route, it took ages and there was this
.fi. everywhere in man pages.
I did this instead for the man pages:
# seen in INSTALL
mkdir manual && cd manual
git init
git fetch-pack git://git.kernel.org/pub/scm/git/git.git man html |
while read a b
    echo $a >.git/$b
cp .git/refs/heads/man .git/refs/heads/master
git checkout
# Aha, now put in where it goes.
for mSect in man[1-8]; do
  if [ -d "$mSect" ]; then
    for mp in $(find ${mSect} -type f); do
      install -o root -g root -m 644 -v $mp /usr/share/man/$mSect/


More information about the blfs-dev mailing list