"Fossies" - the Fresh Open Source Software Archive

Member "git-2.31.1.windows.1/INSTALL" (27 Mar 2021, 10021 Bytes) of package /windows/misc/git-2.31.1.windows.1.zip:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "INSTALL": 2.29.2_vs_2.30.0.

    2 		Git installation
    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
    8 	$ make prefix=/usr all doc info ;# as yourself
    9 	# make prefix=/usr install install-doc install-html install-info ;# as root
   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.
   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.
   20 Alternatively you can use autoconf generated ./configure script to
   21 set up install paths (via config.mak.autogen), so you can write instead
   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
   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
   31 	$ make prefix=/usr profile
   32 	# make prefix=/usr PROFILE=BUILD install
   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.
   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:
   43 	$ make prefix=/usr profile-fast
   44 	# make prefix=/usr PROFILE=BUILD install
   46 Or if you just want to install a profile-optimized version of git into
   47 your home directory, you could run:
   49 	$ make profile-install
   51 or
   52 	$ make profile-fast-install
   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.
   61 Issues of note:
   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.
   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.
   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.
   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:
   85 	GIT_EXEC_PATH=`pwd`
   86 	PATH=`pwd`:$PATH
   87 	GITPERLLIB=`pwd`/perl/build/lib
   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.
   97    Manually supplying a perllibdir prefix should fix this, if this is
   98    a problem you care about, e.g.:
  100        prefix=/usr perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr $Config{installsitelib}, 1 + length $Config{siteprefixexp}')
  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.
  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.
  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.
  115 	- "zlib", the compression library. Git won't build without it.
  117 	- "ssh" is used to push and pull over the net.
  119 	- A POSIX-compliant shell is required to run some scripts needed
  120 	  for everyday use (e.g. "bisect", "request-pull").
  122 	- "Perl" version 5.8 or later is needed to use some of the
  123 	  features (e.g. preparing a partial commit using "git add -i/-p",
  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 http://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.
  132 	- git-imap-send needs the OpenSSL library to talk IMAP over SSL if
  133 	  you are using libcurl older than 7.34.0.  Otherwise you can use
  134 	  NO_OPENSSL without losing git-imap-send.
  136 	  By default, git uses OpenSSL for SHA1 but it will use its own
  137 	  library (inspired by Mozilla's) with either NO_OPENSSL or
  138 	  BLK_SHA1.  Also included is a version optimized for PowerPC
  139 	  (PPC_SHA1).
  141 	- "libcurl" library is used by git-http-fetch, git-fetch, and, if
  142 	  the curl version >= 7.34.0, for git-imap-send.  You might also
  143 	  want the "curl" executable for debugging purposes. If you do not
  144 	  use http:// or https:// repositories, and do not want to put
  145 	  patches into an IMAP mailbox, you do not have to have them
  146 	  (use NO_CURL).
  148 	- "expat" library; git-http-push uses it for remote lock
  149 	  management over DAV.  Similar to "curl" above, this is optional
  150 	  (with NO_EXPAT).
  152 	- "wish", the Tcl/Tk windowing shell is used in gitk to show the
  153 	  history graphically, and in git-gui.  If you don't want gitk or
  154 	  git-gui, you can use NO_TCLTK.
  156 	- A gettext library is used by default for localizing Git. The
  157 	  primary target is GNU libintl, but the Solaris gettext
  158 	  implementation also works.
  160 	  We need a gettext.h on the system for C code, gettext.sh (or
  161 	  Solaris gettext(1)) for shell scripts, and libintl-perl for Perl
  162 	  programs.
  164 	  Set NO_GETTEXT to disable localization support and make Git only
  165 	  use English. Under autoconf the configure script will do this
  166 	  automatically if it can't find libintl on the system.
  168 	- Python version 2.7 or later is needed to use the git-p4 interface
  169 	  to Perforce.
  171  - Some platform specific issues are dealt with Makefile rules,
  172    but depending on your specific installation, you may not
  173    have all the libraries/tools needed, or you may have
  174    necessary libraries at unusual locations.  Please look at the
  175    top of the Makefile to see what can be adjusted for your needs.
  176    You can place local settings in config.mak and the Makefile
  177    will include them.  Note that config.mak is not distributed;
  178    the name is reserved for local settings.
  180  - To build and install documentation suite, you need to have
  181    the asciidoc/xmlto toolchain.  Because not many people are
  182    inclined to install the tools, the default build target
  183    ("make all") does _not_ build them.
  185    "make doc" builds documentation in man and html formats; there are
  186    also "make man", "make html" and "make info". Note that "make html"
  187    requires asciidoc, but not xmlto. "make man" (and thus make doc)
  188    requires both.
  190    "make install-doc" installs documentation in man format only; there
  191    are also "make install-man", "make install-html" and "make
  192    install-info".
  194    Building and installing the info file additionally requires
  195    makeinfo and docbook2X.  Version 0.8.3 is known to work.
  197    Building and installing the pdf file additionally requires
  198    dblatex.  Version >= 0.2.7 is known to work.
  200    All formats require at least asciidoc 8.4.1.
  202    There are also "make quick-install-doc", "make quick-install-man"
  203    and "make quick-install-html" which install preformatted man pages
  204    and html documentation. To use these build targets, you need to
  205    clone two separate git-htmldocs and git-manpages repositories next
  206    to the clone of git itself.
  208    The minimum supported version of docbook-xsl is 1.74.
  210    Users attempting to build the documentation on Cygwin may need to ensure
  211    that the /etc/xml/catalog file looks something like this:
  213    <?xml version="1.0"?>
  214    <!DOCTYPE catalog PUBLIC
  215       "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
  216       "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"
  217    >
  218    <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  219      <rewriteURI
  220        uriStartString = "http://docbook.sourceforge.net/release/xsl/current"
  221        rewritePrefix = "/usr/share/sgml/docbook/xsl-stylesheets"
  222      />
  223      <rewriteURI
  224        uriStartString="http://www.oasis-open.org/docbook/xml/4.5"
  225        rewritePrefix="/usr/share/sgml/docbook/xml-dtd-4.5"
  226      />
  227   </catalog>
  229   This can be achieved with the following two xmlcatalog commands:
  231   xmlcatalog --noout \
  232      --add rewriteURI \
  233         http://docbook.sourceforge.net/release/xsl/current \
  234         /usr/share/sgml/docbook/xsl-stylesheets \
  235      /etc/xml/catalog
  237   xmlcatalog --noout \
  238      --add rewriteURI \
  239          http://www.oasis-open.org/docbook/xml/4.5/xsl/current \
  240          /usr/share/sgml/docbook/xml-dtd-4.5 \
  241      /etc/xml/catalog