A git test drive
ken at linuxfromscratch.org
Thu Oct 28 13:36:43 PDT 2010
On Thu, Oct 28, 2010 at 01:30:43PM -0400, linux fan wrote:
> 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
> ./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.
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
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
I've also seen occasional unexpected results (uncommitted files
disappearing when I changed branches) which are *probably* down to
me doing things wrong.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the blfs-dev