| 1 | |
| 2 | Git installation |
| 3 | |
| 4 | Normally you can just do "make" followed by "make install", and that |
| 5 | will install the git programs in your own ~/bin/ directory. If you want |
| 6 | to do a global install, you can do |
| 7 | |
| 8 | $ make prefix=/usr all doc info ;# as yourself |
| 9 | # make prefix=/usr install install-doc install-html install-info ;# as root |
| 10 | |
| 11 | (or prefix=/usr/local, of course). Just like any program suite |
| 12 | that uses $prefix, the built results have some paths encoded, |
| 13 | which are derived from $prefix, so "make all; make prefix=/usr |
| 14 | install" would not work. |
| 15 | |
| 16 | The beginning of the Makefile documents many variables that affect the way |
| 17 | git is built. You can override them either from the command line, or in a |
| 18 | config.mak file. |
| 19 | |
| 20 | Alternatively you can use autoconf generated ./configure script to |
| 21 | set up install paths (via config.mak.autogen), so you can write instead |
| 22 | |
| 23 | $ make configure ;# as yourself |
| 24 | $ ./configure --prefix=/usr ;# as yourself |
| 25 | $ make all doc ;# as yourself |
| 26 | # make install install-doc install-html;# as root |
| 27 | |
| 28 | If you're willing to trade off (much) longer build time for a later |
| 29 | faster git you can also do a profile feedback build with |
| 30 | |
| 31 | $ make prefix=/usr profile |
| 32 | # make prefix=/usr PROFILE=BUILD install |
| 33 | |
| 34 | This will run the complete test suite as training workload and then |
| 35 | rebuild git with the generated profile feedback. This results in a git |
| 36 | which is a few percent faster on CPU intensive workloads. This |
| 37 | may be a good tradeoff for distribution packagers. |
| 38 | |
| 39 | Alternatively you can run profile feedback only with the git benchmark |
| 40 | suite. This runs significantly faster than the full test suite, but |
| 41 | has less coverage: |
| 42 | |
| 43 | $ make prefix=/usr profile-fast |
| 44 | # make prefix=/usr PROFILE=BUILD install |
| 45 | |
| 46 | Or if you just want to install a profile-optimized version of git into |
| 47 | your home directory, you could run: |
| 48 | |
| 49 | $ make profile-install |
| 50 | |
| 51 | or |
| 52 | $ make profile-fast-install |
| 53 | |
| 54 | As a caveat: a profile-optimized build takes a *lot* longer since the |
| 55 | git tree must be built twice, and in order for the profiling |
| 56 | measurements to work properly, ccache must be disabled and the test |
| 57 | suite has to be run using only a single CPU. In addition, the profile |
| 58 | feedback build stage currently generates a lot of additional compiler |
| 59 | warnings. |
| 60 | |
| 61 | Issues of note: |
| 62 | |
| 63 | - Ancient versions of GNU Interactive Tools (pre-4.9.2) installed a |
| 64 | program "git", whose name conflicts with this program. But with |
| 65 | version 4.9.2, after long hiatus without active maintenance (since |
| 66 | around 1997), it changed its name to gnuit and the name conflict is no |
| 67 | longer a problem. |
| 68 | |
| 69 | NOTE: When compiled with backward compatibility option, the GNU |
| 70 | Interactive Tools package still can install "git", but you can build it |
| 71 | with --disable-transition option to avoid this. |
| 72 | |
| 73 | - You can use git after building but without installing if you want |
| 74 | to test drive it. Simply run git found in bin-wrappers directory |
| 75 | in the build directory, or prepend that directory to your $PATH. |
| 76 | This however is less efficient than running an installed git, as |
| 77 | you always need an extra fork+exec to run any git subcommand. |
| 78 | |
| 79 | It is still possible to use git without installing by setting a few |
| 80 | environment variables, which was the way this was done |
| 81 | traditionally. But using git found in bin-wrappers directory in |
| 82 | the build directory is far simpler. As a historical reference, the |
| 83 | old way went like this: |
| 84 | |
| 85 | GIT_EXEC_PATH=`pwd` |
| 86 | PATH=`pwd`:$PATH |
| 87 | GITPERLLIB=`pwd`/perl/build/lib |
| 88 | export GIT_EXEC_PATH PATH GITPERLLIB |
| 89 | |
| 90 | - By default (unless NO_PERL is provided) Git will ship various perl |
| 91 | scripts. However, for simplicity it doesn't use the |
| 92 | ExtUtils::MakeMaker toolchain to decide where to place the perl |
| 93 | libraries. Depending on the system this can result in the perl |
| 94 | libraries not being where you'd like them if they're expected to be |
| 95 | used by things other than Git itself. |
| 96 | |
| 97 | Manually supplying a perllibdir prefix should fix this, if this is |
| 98 | a problem you care about, e.g.: |
| 99 | |
| 100 | prefix=/usr perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr $Config{installsitelib}, 1 + length $Config{siteprefixexp}') |
| 101 | |
| 102 | Will result in e.g. perllibdir=/usr/share/perl/5.26.1 on Debian, |
| 103 | perllibdir=/usr/share/perl5 (which we'd use by default) on CentOS. |
| 104 | |
| 105 | - Unless NO_PERL is provided Git will ship various perl libraries it |
| 106 | needs. Distributors of Git will usually want to set |
| 107 | NO_PERL_CPAN_FALLBACKS if NO_PERL is not provided to use their own |
| 108 | copies of the CPAN modules Git needs. |
| 109 | |
| 110 | - Git is reasonably self-sufficient, but does depend on a few external |
| 111 | programs and libraries. Git can be used without most of them by adding |
| 112 | the appropriate "NO_<LIBRARY>=YesPlease" to the make command line or |
| 113 | config.mak file. |
| 114 | |
| 115 | - "zlib", the compression library. Git won't build without it. |
| 116 | |
| 117 | - "ssh" is used to push and pull over the net. |
| 118 | |
| 119 | - A POSIX-compliant shell is required to run some scripts needed |
| 120 | for everyday use (e.g. "bisect", "request-pull"). |
| 121 | |
| 122 | - "Perl" version 5.26.0 or later is needed to use some of the |
| 123 | features (e.g. sending patches using "git send-email", |
| 124 | interacting with svn repositories with "git svn"). If you can |
| 125 | live without these, use NO_PERL. Note that recent releases of |
| 126 | Redhat/Fedora are reported to ship Perl binary package with some |
| 127 | core modules stripped away (see https://lwn.net/Articles/477234/), |
| 128 | so you might need to install additional packages other than Perl |
| 129 | itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain, |
| 130 | Net::SMTP, and Time::HiRes. |
| 131 | |
| 132 | - "libcurl" library is used for fetching and pushing |
| 133 | repositories over http:// or https://, as well as by |
| 134 | git-imap-send. If you do not need that functionality, |
| 135 | use NO_CURL to build without it. |
| 136 | |
| 137 | Git requires version "7.61.0" or later of "libcurl" to build |
| 138 | without NO_CURL. This version requirement may be bumped in |
| 139 | the future. |
| 140 | |
| 141 | - "expat" library; git-http-push uses it for remote lock |
| 142 | management over DAV. Similar to "curl" above, this is optional |
| 143 | (with NO_EXPAT). |
| 144 | |
| 145 | - "wish", the Tcl/Tk windowing shell is used in gitk to show the |
| 146 | history graphically, and in git-gui. If you don't want gitk or |
| 147 | git-gui, you can use NO_TCLTK. |
| 148 | |
| 149 | - A gettext library is used by default for localizing Git. The |
| 150 | primary target is GNU libintl, but the Solaris gettext |
| 151 | implementation also works. |
| 152 | |
| 153 | We need a gettext.h on the system for C code, gettext.sh (or |
| 154 | Solaris gettext(1)) for shell scripts, and libintl-perl for Perl |
| 155 | programs. |
| 156 | |
| 157 | Set NO_GETTEXT to disable localization support and make Git only |
| 158 | use English. Under autoconf the configure script will do this |
| 159 | automatically if it can't find libintl on the system. |
| 160 | |
| 161 | - Python version 2.7 or later is needed to use the git-p4 interface |
| 162 | to Perforce. |
| 163 | |
| 164 | - Some platform specific issues are dealt with Makefile rules, |
| 165 | but depending on your specific installation, you may not |
| 166 | have all the libraries/tools needed, or you may have |
| 167 | necessary libraries at unusual locations. Please look at the |
| 168 | top of the Makefile to see what can be adjusted for your needs. |
| 169 | You can place local settings in config.mak and the Makefile |
| 170 | will include them. Note that config.mak is not distributed; |
| 171 | the name is reserved for local settings. |
| 172 | |
| 173 | - To build and install documentation suite, you need to have |
| 174 | the asciidoc/xmlto toolchain. Because not many people are |
| 175 | inclined to install the tools, the default build target |
| 176 | ("make all") does _not_ build them. |
| 177 | |
| 178 | "make doc" builds documentation in man and html formats; there are |
| 179 | also "make man", "make html" and "make info". Note that "make html" |
| 180 | requires asciidoc, but not xmlto. "make man" (and thus make doc) |
| 181 | requires both. |
| 182 | |
| 183 | "make install-doc" installs documentation in man format only; there |
| 184 | are also "make install-man", "make install-html" and "make |
| 185 | install-info". |
| 186 | |
| 187 | Building and installing the info file additionally requires |
| 188 | makeinfo and docbook2X. Version 0.8.3 is known to work. |
| 189 | |
| 190 | Building and installing the pdf file additionally requires |
| 191 | dblatex. Version >= 0.2.7 is known to work. |
| 192 | |
| 193 | All formats require at least asciidoc 8.4.1. Alternatively, you can |
| 194 | use Asciidoctor (requires Ruby) by passing USE_ASCIIDOCTOR=YesPlease |
| 195 | to make. You need at least Asciidoctor version 1.5. |
| 196 | |
| 197 | There are also "make quick-install-doc", "make quick-install-man" |
| 198 | and "make quick-install-html" which install preformatted man pages |
| 199 | and html documentation. To use these build targets, you need to |
| 200 | clone two separate git-htmldocs and git-manpages repositories next |
| 201 | to the clone of git itself. |
| 202 | |
| 203 | The minimum supported version of docbook-xsl is 1.74. |
| 204 | |
| 205 | Users attempting to build the documentation on Cygwin may need to ensure |
| 206 | that the /etc/xml/catalog file looks something like this: |
| 207 | |
| 208 | <?xml version="1.0"?> |
| 209 | <!DOCTYPE catalog PUBLIC |
| 210 | "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" |
| 211 | "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd" |
| 212 | > |
| 213 | <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> |
| 214 | <rewriteURI |
| 215 | uriStartString = "http://docbook.sourceforge.net/release/xsl/current" |
| 216 | rewritePrefix = "/usr/share/sgml/docbook/xsl-stylesheets" |
| 217 | /> |
| 218 | <rewriteURI |
| 219 | uriStartString="http://www.oasis-open.org/docbook/xml/4.5" |
| 220 | rewritePrefix="/usr/share/sgml/docbook/xml-dtd-4.5" |
| 221 | /> |
| 222 | </catalog> |
| 223 | |
| 224 | This can be achieved with the following two xmlcatalog commands: |
| 225 | |
| 226 | xmlcatalog --noout \ |
| 227 | --add rewriteURI \ |
| 228 | http://docbook.sourceforge.net/release/xsl/current \ |
| 229 | /usr/share/sgml/docbook/xsl-stylesheets \ |
| 230 | /etc/xml/catalog |
| 231 | |
| 232 | xmlcatalog --noout \ |
| 233 | --add rewriteURI \ |
| 234 | http://www.oasis-open.org/docbook/xml/4.5/xsl/current \ |
| 235 | /usr/share/sgml/docbook/xml-dtd-4.5 \ |
| 236 | /etc/xml/catalog |