|
|
|
|
|
|
|
Git installation
|
|
|
|
|
|
|
|
Normally you can just do "make" followed by "make install", and that
|
|
|
|
will install the git programs in your own ~/bin/ directory. If you want
|
|
|
|
to do a global install, you can do
|
|
|
|
|
|
|
|
$ make prefix=/usr all doc ;# as yourself
|
|
|
|
# make prefix=/usr install install-doc ;# as root
|
|
|
|
|
|
|
|
(or prefix=/usr/local, of course). Just like any program suite
|
|
|
|
that uses $prefix, the built results have some paths encoded,
|
|
|
|
which are derived from $prefix, so "make all; make prefix=/usr
|
|
|
|
install" would not work.
|
|
|
|
|
|
|
|
Alternatively you can use autoconf generated ./configure script to
|
|
|
|
set up install paths (via config.mak.autogen), so you can write instead
|
|
|
|
|
|
|
|
$ make configure ;# as yourself
|
|
|
|
$ ./configure --prefix=/usr ;# as yourself
|
|
|
|
$ make all doc ;# as yourself
|
|
|
|
# make install install-doc ;# as root
|
|
|
|
|
|
|
|
|
|
|
|
Issues of note:
|
|
|
|
|
|
|
|
- git normally installs a helper script wrapper called "git", which
|
|
|
|
conflicts with a similarly named "GNU interactive tools" program.
|
|
|
|
|
|
|
|
Tough. Either don't use the wrapper script, or delete the old GNU
|
|
|
|
interactive tools. None of the core git stuff needs the wrapper,
|
|
|
|
it's just a convenient shorthand and while it is documented in some
|
|
|
|
places, you can always replace "git commit" with "git-commit"
|
|
|
|
instead.
|
|
|
|
|
|
|
|
But let's face it, most of us don't have GNU interactive tools, and
|
|
|
|
even if we had it, we wouldn't know what it does. I don't think it
|
|
|
|
has been actively developed since 1997, and people have moved over to
|
|
|
|
graphical file managers.
|
|
|
|
|
|
|
|
- You can use git after building but without installing if you
|
|
|
|
wanted to. Various git commands need to find other git
|
|
|
|
commands and scripts to do their work, so you would need to
|
|
|
|
arrange a few environment variables to tell them that their
|
|
|
|
friends will be found in your built source area instead of at
|
|
|
|
their standard installation area. Something like this works
|
|
|
|
for me:
|
|
|
|
|
|
|
|
GIT_EXEC_PATH=`pwd`
|
|
|
|
PATH=`pwd`:$PATH
|
|
|
|
GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
|
|
|
|
export GIT_EXEC_PATH PATH GITPERLLIB
|
|
|
|
|
|
|
|
- Git is reasonably self-sufficient, but does depend on a few external
|
|
|
|
programs and libraries:
|
|
|
|
|
|
|
|
- "zlib", the compression library. Git won't build without it.
|
|
|
|
|
|
|
|
- "openssl". The git-rev-list program uses bignum support from
|
|
|
|
openssl, and unless you specify otherwise, you'll also get the
|
|
|
|
SHA1 library from here.
|
|
|
|
|
|
|
|
If you don't have openssl, you can use one of the SHA1 libraries
|
|
|
|
that come with git (git includes the one from Mozilla, and has
|
|
|
|
its own PowerPC and ARM optimized ones too - see the Makefile).
|
|
|
|
|
|
|
|
- "libcurl" and "curl" executable. git-http-fetch and
|
|
|
|
git-fetch use them. If you do not use http
|
|
|
|
transfer, you are probably OK if you do not have
|
|
|
|
them.
|
|
|
|
|
|
|
|
- expat library; git-http-push uses it for remote lock
|
|
|
|
management over DAV. Similar to "curl" above, this is optional.
|
|
|
|
|
|
|
|
- "GNU diff" to generate patches. Of course, you don't _have_ to
|
|
|
|
generate patches if you don't want to, but let's face it, you'll
|
|
|
|
be wanting to. Or why did you get git in the first place?
|
|
|
|
|
|
|
|
Non-GNU versions of the diff/patch programs don't generally support
|
|
|
|
the unified patch format (which is the one git uses), so you
|
|
|
|
really do want to get the GNU one. Trust me, you will want to
|
|
|
|
do that even if it wasn't for git. There's no point in living
|
|
|
|
in the dark ages any more.
|
|
|
|
|
|
|
|
- "merge", the standard UNIX three-way merge program. It usually
|
|
|
|
comes with the "rcs" package on most Linux distributions, so if
|
|
|
|
you have a developer install you probably have it already, but a
|
|
|
|
"graphical user desktop" install might have left it out.
|
|
|
|
|
|
|
|
You'll only need the merge program if you do development using
|
|
|
|
git, and if you only use git to track other peoples work you'll
|
|
|
|
never notice the lack of it.
|
|
|
|
|
|
|
|
- "wish", the Tcl/Tk windowing shell is used in gitk to show the
|
|
|
|
history graphically
|
|
|
|
|
|
|
|
- "ssh" is used to push and pull over the net
|
|
|
|
|
|
|
|
- "perl" and POSIX-compliant shells are needed to use most of
|
|
|
|
the barebone Porcelainish scripts.
|
|
|
|
|
|
|
|
- "python" 2.3 or more recent; if you have 2.3, you may need
|
|
|
|
to build with "make WITH_OWN_SUBPROCESS_PY=YesPlease".
|
|
|
|
|
|
|
|
- Some platform specific issues are dealt with Makefile rules,
|
|
|
|
but depending on your specific installation, you may not
|
|
|
|
have all the libraries/tools needed, or you may have
|
|
|
|
necessary libraries at unusual locations. Please look at the
|
|
|
|
top of the Makefile to see what can be adjusted for your needs.
|
|
|
|
You can place local settings in config.mak and the Makefile
|
|
|
|
will include them. Note that config.mak is not distributed;
|
|
|
|
the name is reserved for local settings.
|
|
|
|
|
|
|
|
- To build and install documentation suite, you need to have the
|
|
|
|
asciidoc/xmlto toolchain. Alternatively, pre-formatted
|
|
|
|
documentation are available in "html" and "man" branches of the git
|
|
|
|
repository itself. For example, you could:
|
|
|
|
|
|
|
|
$ mkdir manual && cd manual
|
|
|
|
$ git init-db
|
|
|
|
$ 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
|
|
|
|
|
|
|
|
to checkout the pre-built man pages. Also in this repository:
|
|
|
|
|
|
|
|
$ git checkout html
|
|
|
|
|
|
|
|
would instead give you a copy of what you see at:
|
|
|
|
|
|
|
|
http://www.kernel.org/pub/software/scm/git/docs/
|
|
|
|
|