|  | 
 | 		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/ | 
 |  |