summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2012-08-08Merge branch 'bw/maint-1.7.9-solaris-getpass'Libravatar Junio C Hamano1-0/+1
The recent update to terminal I/O interface to get passwords &c interactively didn't quite work on Solaris. * bw/maint-1.7.9-solaris-getpass: Enable HAVE_DEV_TTY for Solaris terminal: seek when switching between reading and writing
2012-08-06Enable HAVE_DEV_TTY for SolarisLibravatar Ben Walton1-0/+1
Now that git_terminal_prompt can cleanly interact with /dev/tty on Solaris, enable HAVE_DEV_TTY so that this code path is used for credential reading instead of relying on the crippled getpass(). Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06Makefile: use overridable $(FIND) instead of hard-coded 'find'Libravatar Johannes Sixt1-1/+1
The Makefile already offers the variable $(FIND) and uses it except in one place. Fix it. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31Merge branch 'jx/i18n-1.7.11'Libravatar Junio C Hamano1-1/+2
Add i18n support for scripted Porcelains, and mark strings in merge(-recursive), am, and rebase for i18n. * jx/i18n-1.7.11: i18n: merge-recursive: mark strings for translation Remove dead code which contains bad gettext block i18n: am: mark more strings for translation rebase: remove obsolete and unused LONG_USAGE which breaks xgettext i18n: Rewrite gettext messages start with dash i18n: rebase: mark messages for translation i18n: New keywords for xgettext extraction from sh
2012-07-27perl: detect new files in MakeMaker buildsLibravatar Junio C Hamano1-0/+7
While Makefile.PL now finds .pm files on its own, it does not detect new files after it generates perl/perl.mak. [ew: commit message, minor tweaks] ref: http://mid.gmane.org/7vlii51xz4.fsf@alter.siamese.dyndns.org Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-25i18n: New keywords for xgettext extraction from shLibravatar Jiang Xin1-1/+2
Since we have additional shell wrappers (gettextln and eval_gettextln) for gettext, we need to take into account these wrappers when running 'make pot' to extract messages from shell scripts. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Stefano Lattarini <stefano.lattarini@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-23Merge branch 'jn/block-sha1'Libravatar Junio C Hamano1-3/+2
The code to load a word one-byte-at-a-time was optimized into a word-wide load instruction even when the pointer was not aligned, which caused issues on architectures that do not like unaligned access. * jn/block-sha1: Makefile: BLK_SHA1 does not require fast htonl() and unaligned loads block-sha1: put expanded macro parameters in parentheses block-sha1: avoid pointer conversion that violates alignment constraints
2012-07-23Merge branch 'jn/make-assembly-in-right-directory'Libravatar Junio C Hamano1-1/+1
* jn/make-assembly-in-right-directory: Makefile: fix location of listing produced by "make subdir/foo.s"
2012-07-23Makefile: BLK_SHA1 does not require fast htonl() and unaligned loadsLibravatar Jonathan Nieder1-3/+2
block-sha1/ is fast on most known platforms. Clarify the Makefile to be less misleading about that. Early versions of block-sha1/ explicitly relied on fast htonl() and fast 32-bit loads with arbitrary alignment. Now it uses those on some arches but the default behavior is byte-at-a-time access for the sake of arches like ARM, Alpha, and their kin and it is still pretty fast on these arches (fast enough to supersede the mozilla SHA1 implementation and the hand-written ARM assembler implementation that were bundled before). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Makefile: fix location of listing produced by "make subdir/foo.s"Libravatar Jonathan Nieder1-1/+1
When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without specifying where it should put its output and the output ends up in ./sha1.s. Confusing. Add an -o option to the .s rule to fix this. We were already doing that for most compiler invocations but had forgotten it for the assembler listings. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-19build: reconfigure automatically if configure.ac changesLibravatar Stefano Lattarini1-0/+12
This provides a reduced but still useful sibling of the Automake's "automatic Makefile rebuild" feature. It's important to note that we take care to enable the new rules only if the tree that has already be configured with './configure', so that users relying on manual configuration won't be negatively impacted. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-19build: "make clean" should not remove configure-generated filesLibravatar Stefano Lattarini1-2/+3
Those filed hold variables, settings and information set by the configuration process run by './configure'; in Autotools-based build system that kind of stuff should only be removed by "make distclean". Having it removed by "make clean" is not only inconsistent, but causes real confusion for that part of the Git audience that is used to the Autotools semantics; for example, an autotools old-timer that has run: ./configure --prefix /opt/git in the past, without running "make distclean" afterwards, would expect a "make install" issued after a "make clean" to rebuild and install git in '/opt/git'; but with the current behaviour, the "make clean" invocation removes (among the other things) the file 'config.mak.autogen', so that the "make install" falls back to the default prefix of '$HOME', thus installing git in the user's home directory -- definitely unexpected. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-15Merge branch 'jn/makefile-cleanup'Libravatar Junio C Hamano1-102/+128
Tightens dependency rules to avoid unnecessary recompilation, and cleans up our Makefile in general. * jn/makefile-cleanup: Makefile: document ground rules for target-specific dependencies Makefile: move GIT-VERSION-FILE dependencies closer to use Makefile: build instaweb similar to other scripts Makefile: update scripts when build-time parameters change Makefile: do not replace @@GIT_VERSION@@ in shell scripts Makefile: split prefix flags from GIT-CFLAGS Makefile: be silent when only GIT_USER_AGENT changes Makefile: split GIT_USER_AGENT from GIT-CFLAGS Makefile: do not replace @@GIT_USER_AGENT@@ in scripts Makefile: apply dependencies consistently to sparse/asm targets Makefile: do not have git.o depend on common-cmds.h Makefile: fold XDIFF_H and VCSSVN_H into LIB_H Makefile: fold MISC_H into LIB_H Makefile: sort LIB_H list
2012-07-13Merge branch 'tb/sanitize-decomposed-utf-8-pathname'Libravatar Junio C Hamano1-0/+3
Teaches git to normalize pathnames read from readdir(3) and all arguments from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8) to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * tb/sanitize-decomposed-utf-8-pathname: git on Mac OS and precomposed unicode
2012-07-09Merge branch 'mm/credential-plumbing'Libravatar Junio C Hamano1-1/+1
Expose the credential API to scripted Porcelain writers. * mm/credential-plumbing: git-remote-mediawiki: update comments to reflect credential support git-remote-mediawiki: add credential support git credential fill: output the whole 'struct credential' add 'git credential' plumbing command
2012-07-09Merge branch 'rj/platform-pread-may-be-thread-unsafe'Libravatar Junio C Hamano1-0/+8
On Cygwin, the platform pread(3) is not thread safe, just like our own compat/ emulation, and cannot be used in the index-pack program. * rj/platform-pread-may-be-thread-unsafe: index-pack: Disable threading on cygwin
2012-07-09Makefile: document ground rules for target-specific dependenciesLibravatar Jonathan Nieder1-0/+33
When a source file makes use of a makefile variable, there should be a corresponding dependency on a file that changes when that variable changes to ensure the build output is not left stale when the variable changes. Document this, even though we are not following the rule perfectly yet. Based on an explanation from Jeff King. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: move GIT-VERSION-FILE dependencies closer to useLibravatar Jeff King1-9/+4
There is a list of all of the targets which depend on GIT-VERSION-FILE, but it can be quite far from the actual point where the targets actually use $(GIT_VERSION). This can make it hard to verify that each use of $(GIT_VERSION) has a matching dependency. This patch moves the dependency closer to the actual build instructions, which makes verification easier. This also fixes the generation of "configure", which did not properly mark the dependency. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: build instaweb similar to other scriptsLibravatar Jeff King1-8/+6
Instaweb would not properly rebuild if the build-time parameters changed. Fix this by depending on the GIT-SCRIPT-DEFINES meta-file and using $(cmd_munge_script) like all the other shell scripts. This requires adding a few new parametres to cmd_munge_script, but that doesn't hurt existing scripts. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: update scripts when build-time parameters changeLibravatar Jeff King1-3/+13
Currently, running: make SHELL_PATH=/bin/bash && make SHELL_PATH=/bin/sh will not rebuild any shell scripts in the second command, leading to incorrect results when building from an unclean working directory. This patch introduces a new dependency meta-file to notice the change. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: do not replace @@GIT_VERSION@@ in shell scriptsLibravatar Jeff King1-3/+0
No shell script actually uses the replacement (it is used in some perl scripts, but cmd_munge_script only handles shell scripts). We can also therefore drop the dependency on GIT-VERSION-FILE. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: split prefix flags from GIT-CFLAGSLibravatar Jeff King1-8/+22
Most of the build targets do not care about the setting of $prefix (or its derivative variables), but will be rebuilt if the prefix changes. For most setups this doesn't matter (they set prefix once and never change it), but for a setup which puts each branch or version in its own prefix, this unnecessarily causes a full rebuild whenever the branc is changed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: be silent when only GIT_USER_AGENT changesLibravatar Jonathan Nieder1-1/+0
To avoid noise during builds, unlike the GIT-CFLAGS rule which prints "* new build flags or prefix" so the operator knows why all files are being rebuilt when it changes, GIT-USER-AGENT generation is silent. If this code breaks and a target depending on GIT-USER-AGENT ends up being rebuilt when it shouldn't be, the full dependency chain can be retrieved with "make --debug=b". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: split GIT_USER_AGENT from GIT-CFLAGSLibravatar Jeff King1-2/+9
The default user-agent depends on the GIT_VERSION, which means that anytime you switch versions, it causes a full rebuild. Instead, let's split it out into its own file and restrict the dependency to version.o. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: do not replace @@GIT_USER_AGENT@@ in scriptsLibravatar Jeff King1-1/+0
No scripts actually care about this replacement. This was erroneously added by 42dcbb7 (version: add git_user_agent function, 2012-06-02). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: apply dependencies consistently to sparse/asm targetsLibravatar Jeff King1-2/+2
When a C file "foo.c" depends on a generated header file, we note the dependency for the "foo.o" target. However, we should also note it for other targets that are built from foo.c, like "foo.sp" and "foo.s". These tend to be missed because the latter two are not part of the default build, and are typically built after a regular build which will generate the header. Let's be consistent about including them in dependencies. This also makes us more consistent with nearby lines which tack on EXTRA_CPPFLAGS when building certain files. These flags may sometimes require extra dependencies to be added (e.g., like GIT-VERSION-FILE; this is not the case for any of the updated lines in this patch, but it is establishing a style that will be used in later patches). Technically the ".sp" and ".s" targets do not care about these dependencies, because they are force-built (".sp" because it is a phony target, and ".s" because we explicitly force a rebuild). Since the blocks in question are about communicating "things built from foo.c depend on these flags", it frees the reader from having to know or care more about how those targets are implemented, and why it is OK for only "foo.o" to depend on GIT-VERSION-FILE while "foo.sp" and "foo.s" both are impacted by $(GIT_VERSION). And it helps future-proof us if those force-build details should ever change. This patch explicitly does not update the static header dependencies used when COMPUTED_HEADER_DEPENDENCIES is off. They are similar to the GIT-VERSION-FILE case above, in that technically "foo.s" would depend on its included headers, but it is irrelevant because we force-build it anyway. So it would be tempting to update them in the same way (for readability and future-proofing). However, those rules are meant as a fallback to the computed header dependencies, which do not handle ".s" and ".sp" at all (and are a much harder problem to solve, as gcc is the one generating those dependency lists). So let's leave that harder problem until (and if) somebody wants to change the ".sp" and ".s" rules, and keep the static header dependencies consistent with the computed ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: do not have git.o depend on common-cmds.hLibravatar Jeff King1-1/+0
This dependency has been stale since 70827b1 (Split up builtin commands into separate files from git.c, 2006-04-21). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Makefile: fold XDIFF_H and VCSSVN_H into LIB_HLibravatar Jonathan Nieder1-37/+25
Just like MISC_H (see previous commit), there is no reason to track xdiff and vcs-svn headers separately from the rest of the headers. The only purpose of these variables is to keep track of recompilation dependencies. As a pleasant side effect, folding these into LIB_H lets us stop tracking GIT_OBJS and VCSSVN_TEST_OBJS separately from the list of all OBJECTS. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-08git on Mac OS and precomposed unicodeLibravatar Torsten Bögershausen1-0/+3
Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. When creating a new git repository with "git init" or "git clone", "core.precomposedunicode" will be set "false". The user needs to activate this feature manually. She typically sets core.precomposedunicode to "true" on HFS and VFAT, or file systems mounted via SAMBA. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-26index-pack: Disable threading on cygwinLibravatar Junio C Hamano1-0/+8
The Cygwin implementation of pread() is not thread-safe since, just like the emulation provided by compat/pread.c, it uses a sequence of seek-read-seek calls. In order to avoid failues due to thread-safety issues, commit b038a61 disables threading when NO_PREAD is defined. (ie when using the emulation code in compat/pread.c). We introduce a new build variable, NO_THREAD_SAFE_PREAD, which allows use to disable the threaded index-pack code on cygwin, in addition to the above NO_PREAD case. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25add 'git credential' plumbing commandLibravatar Javier Roucher Iglesias1-1/+1
The credential API is in C, and not available to scripting languages. Expose the functionalities of the API by wrapping them into a new plumbing command "git credentials". In other words, replace the internal "test-credential" by an official Git command. Most documentation writen by: Jeff King <peff@peff.net> Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr> Signed-off-by: Kim Thuat Nguyen <Kim-Thuat.Nguyen@ensimag.imag.fr> Signed-off-by: Javier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25Merge branch 'jk/no-more-asciidoc7'Libravatar Junio C Hamano1-6/+0
We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style. * jk/no-more-asciidoc7: docs: drop antique comment from Makefile docs: drop asciidoc7compatible flag
2012-06-21Merge branch 'vr/help-per-platform'Libravatar Junio C Hamano1-0/+9
We used to always default to "man" format even on platforms where "man" viewer is not widely available. * vr/help-per-platform: help: use HTML as the default help format on Windows
2012-06-20Makefile: fold MISC_H into LIB_HLibravatar Jeff King1-29/+16
We keep a list of most of the header files in LIB_H, but some are split out into MISC_H. The original point of LIB_H was that it would force recompilation of C files when any of the library headers changed. It was over-encompassing, since not all C files included all of the library headers; this made it simple to maintain, but meant that we sometimes recompiled when it was not necessary. Over time, some new headers were omitted from LIB_H, and rules were added to the Makefile for a few specific targets to explicitly depend on them. This avoided some unnecessary recompilation at the cost of having to maintain the dependency list of those targets manually (e.g., d349a03). Later, we needed a complete list of headers from which we should extract strings to localized. Thus 1b8b2e4 introduced MISC_H to mention all header files not included in LIB_H, and the concatenation of the two lists is fed to xgettext. Headers mentioned as dependencies must also be manually added to MISC_H to receive the benefits of localization. Having to update multiple locations manually is a pain and has led to errors. For example, see "git log -Swt-status.h Makefile" for some back-and-forth between the two locations. Or the fact that column.h was never added to MISC_H, and therefore was not localized (which is fixed by this patch). Moreover, the benefits of keeping these few headers out of LIB_H is not that great, for two reasons: 1. The better way to do this is by auto-computing the dependencies, which is more accurate and less work to maintain. If your compiler supports it, we turn on computed header dependencies by default these days. So these manual dependencies are used only for people who do not have gcc at all (which increases the chance of them becoming stale, as many developers will never even use them). 2. Even if you do not have gcc, the manual header dependencies do not help all that much. They obviously cannot help with an initial compilation (since their purpose is to avoid unnecessary recompilation when a header changes), which means they are only useful when building a new version of git in the working tree that held an existing build (e.g., after checkout or during a bisection). But since a change of a header in LIB_H will force recompilation, and given that the vast majority of headers are in LIB_H, most version changes will result in a full rebuild anyway. Let's just fold MISC_H into LIB_H and get rid of these manual rules. The worst case is some extra compilation, but even that is unlikely to matter due to the reasons above. The one exception is that we should keep common-cmds.h separate. Because it is generated, the computed dependencies do not handle it properly, and we must keep separate individual dependencies on it. Let's therefore rename MISC_H to GENERATED_H to make it more clear what should go in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-20Makefile: sort LIB_H listLibravatar Jeff King1-4/+4
This was mostly sorted already, but put things like "cache-tree.h" after "cache.h", even though "-" comes before "." (at least in the C locale). This will make it easier to keep the list sorted later by piping it through "sort". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-06help: use HTML as the default help format on WindowsLibravatar Vincent van Ravesteijn1-0/+9
When 'git help $cmd' is run without a format option (e.g. -w), the 'man' format is always used. On some platforms, however, manual page viewers are not often available. Introduce DEFAULT_HELP_FORMAT make variable in order to allow the default format configurable at compile time, and set it to HTML when compiling on Windows (but not Cygwin). Helped-by: Jeff King <peff@peff.net> Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03http: get default user-agent from git_user_agentLibravatar Jeff King1-4/+1
This means we will respect the GIT_USER_AGENT build-time configuration and run-time environment variable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03version: add git_user_agent functionLibravatar Jeff King1-0/+11
This is basically a fancy way of saying "git/$GIT_VERSION", except that it is overridable at build-time and through the environment. Which means that people who don't want to advertise their git version (for privacy or security reasons) can tweak it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03move git_version_string into version.cLibravatar Jeff King1-2/+6
The global git_version_string currently lives in git.c, but doesn't have anything to do with the git wrapper. Let's move it into its own file, where it will be more appropriate to build more version-related functions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Sync with maintLibravatar Junio C Hamano1-1/+1
2012-06-01Merge branch 'ef/http-o-depends-on-gvf' into maintLibravatar Junio C Hamano1-1/+1
A minor compilation fix. By Erik Faye-Lund * ef/http-o-depends-on-gvf: Makefile: add missing GIT-VERSION-FILE dependency
2012-05-31Makefile: add missing GIT-VERSION-FILE dependencyLibravatar Erik Faye-Lund1-1/+1
In 20fc9bc (Set HTTP user agent to git/GIT_VERSION, 2006-04-04), http.o started recording GIT_VERSION, but http.o wasn't added to the list of files that depends on GIT-VERSION-FILE. Fix this, so mofications to GIT-VERSION-FILE will result in an updated user-agent string. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-30docs: drop asciidoc7compatible flagLibravatar Jeff King1-6/+0
When we made the switch to supporting asciidoc 8 in 4c7100a (Documentation: adjust to AsciiDoc 8, 2007-06-14), we were able to leave most of the documentation intact by defining asciidoc7compatible. Since commit 6cf378f (docs: stop using asciidoc no-inline-literal, 2012-04-26), we don't support versions of asciidoc older than 8.4.1, which is when inline literals were introduced. Therefore there is not much point in keeping our documentation compatible with asciidoc 7. So we are now free to drop the asciidoc7compatible flag and update the documentation itself to assume asciidoc8. Fortunately, doing the latter is very easy; we weren't using any of the constructs impacted by asciidoc7compatible, so there are no changes to make. The reason is somewhat subtle. The asciidoc7compatible affects only super/sub-scripts ("^" and "~") and index terms. We don't use the latter at all. Nor we do we use the former, but we did have to protect them from accidental expansion in constructs like "rev^1". However, all of our uses of "~" and "^" are either in code blocks (which are rendered literally), or inside backticks. Prior to 6cf378f, backticks were not inline literals, and needed proper quoting. But post-6cf378f, we don't have to worry whether we are using the old or new rules, as those characters are not interpreted at all in either case. I verified that the result of "make install-html install-man" is identical before and after this patch on asciidoc 8.6.7. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-14Merge branch 'nd/threaded-index-pack'Libravatar Junio C Hamano1-1/+1
Enables threading in index-pack to resolve base data in parallel. By Nguyễn Thái Ngọc Duy (3) and Ramsay Jones (1) * nd/threaded-index-pack: index-pack: disable threading if NO_PREAD is defined index-pack: support multithreaded delta resolving index-pack: restructure pack processing into three main functions compat/win32/pthread.h: Add an pthread_key_delete() implementation
2012-05-10Merge branch 'jc/install-no-hardlinks'Libravatar Junio C Hamano1-1/+11
Your build platform may support hardlinks but you may prefer not to use them, e.g. when installing to DESTDIR to make a tarball and untarring on a filesystem that has poor support for hardlinks. The Makefile in git-gui project may need to learn to honor the same setting; it unconditionally creates git-citool by hardlinking git-gui. * jc/install-no-hardlinks: Makefile: NO_INSTALL_HARDLINKS
2012-05-07index-pack: support multithreaded delta resolvingLibravatar Nguyễn Thái Ngọc Duy1-1/+1
This puts delta resolving on each base on a separate thread, one base cache per thread. Per-thread data is grouped in struct thread_local. When running with nr_threads == 1, no pthreads calls are made. The system essentially runs in non-thread mode. An experiment on a Xeon 24 core machine with git.git shows that performance does not increase proportional to the number of cores. So by default, we use maximum 3 cores. Some numbers with --threads from 1 to 16: 1..4 real 0m8.003s 0m5.307s 0m4.321s 0m3.830s user 0m7.720s 0m8.009s 0m8.133s 0m8.305s sys 0m0.224s 0m0.372s 0m0.360s 0m0.360s 5..8 real 0m3.727s 0m3.604s 0m3.332s 0m3.369s user 0m9.361s 0m9.817s 0m9.525s 0m9.769s sys 0m0.584s 0m0.624s 0m0.540s 0m0.560s 9..12 real 0m3.036s 0m3.139s 0m3.177s 0m2.961s user 0m8.977s 0m10.205s 0m9.737s 0m10.073s sys 0m0.596s 0m0.680s 0m0.684s 0m0.680s 13..16 real 0m2.985s 0m2.894s 0m2.975s 0m2.971s user 0m9.825s 0m10.573s 0m10.833s 0m11.361s sys 0m0.788s 0m0.732s 0m0.904s 0m1.016s On an Intel dual core and linux-2.6.git 1..4 real 2m37.789s 2m7.963s 2m0.920s 1m58.213s user 2m28.415s 2m52.325s 2m50.176s 2m41.187s sys 0m7.808s 0m11.181s 0m11.224s 0m10.731s Thanks Ramsay Jones for troubleshooting and support on MinGW platform. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04Makefile: NO_INSTALL_HARDLINKSLibravatar Junio C Hamano1-1/+11
Your filesystem may support hardlinks, but you may choose not to use them when installing git-foo builtins and favor symblic links or copies for whatever reason. The installation procedure of git-gui/ directory is not touched with this patch and git-citool still ends up being a hardlink to git-gui, but it needs to be addressed separately. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04Makefile: keep many variable list sortedLibravatar Nguyễn Thái Ngọc Duy1-13/+13
We tend to keep long lists sorted (extensions are not taken into account), which helps spot a name easily by eye. Rearrange a few items so these lists remain sorted. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-03Merge branch 'nd/columns'Libravatar Junio C Hamano1-0/+3
A couple of commands learn --column option to produce columnar output. By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1) * nd/columns: tag: add --column column: support piping stdout to external git-column process status: add --column branch: add --column help: reuse print_columns() for help -a column: add dense layout support t9002: work around shells that are unable to set COLUMNS to 1 column: add columnar layout Stop starting pager recursively Add column layout skeleton and git-column
2012-05-02Merge branch 'tr/xdiff-fast-hash'Libravatar Junio C Hamano1-0/+12
Use word-at-a-time comparison to find end of line or NUL (end of buffer), borrowed from the linux-kernel discussion. By Thomas Rast * tr/xdiff-fast-hash: xdiff: choose XDL_FAST_HASH code on sizeof(long) instead of __WORDSIZE xdiff: load full words in the inner loop of xdl_hash_record