FYI 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 requirement. 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) http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh 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 method. ./configure --prefix=/usr \ --without-curl \ --without-tcltk \ --sysconfdir=/etc \ --libexecdir=/usr/lib/git \ --localstatedir=/var make 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 do echo $a >.git/$b done 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/ done fi done FYI -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
