You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
136 lines
5.1 KiB
136 lines
5.1 KiB
|
|
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 |
|
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/ |
|
|
|
|