On Thu, Oct 28, 2010 at 01:30:43PM -0400, linux fan wrote: > FYI > > I like git. > I'll share my curiosity in case anyone is curious about git.
[...] > > 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. Thanks for these notes, I'll try to find time to look at the details of git-svn in a week or two (I've got git-1.6.6 on my home server, together with a now quite old subversion, as well as the blfs and lfs repos, so *in theory* I don't need a lot extra. OTOH, since I do all my development alone, and I'm still unconvinced that git is the best tool for the books [ e.g. linear revision numbers are a lot easier than random hex numbers ], I'm not expecting much useful to come out of that. > > 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. When I put it on my server, I did it manually, and I don't have manpages there - a missing dependency, but I forget what. After that, I did build it on a desktop last summer - and I think I got manpages - but again on a system without tcl/tk. The buildscript for that build *is* under git control, and it looks as if I only had to specify prefix, sysconfdir, libexecdir. However, the problem in building without xorg and tk is that you can't do gitk during a bisect. I remember Dan suggested an ncurses alternative : http://jonas.nitro.dk/tig/ (use the graph mode - 'g') but that's among the many things still on my ToDo list. After about 5 months of using git to hold my scripts, it's mostly great and the help usually gets to the right place in the end. But like everything else, it has to be learned. I've now got two rules of thumb - *always* use a branch when developing, and check commits: both what you are committing (as distinct from what you *think* you are committing), and the commit message. If you screw up the message, fixing it immediately (while it's still HEAD) is straightforward, but fixing it later is an order of magnitude harder. I've also seen occasional unexpected results (uncommitted files disappearing when I changed branches) which are *probably* down to me doing things wrong. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
