summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2012-09-14Sync with 1.7.11.7Libravatar Junio C Hamano1-0/+1
2012-09-14Merge branch 'rj/test-regex' into maint-1.7.11Libravatar Junio C Hamano1-0/+1
* rj/test-regex: test-regex: Add a test to check for a bug in the regex routines
2012-09-11Merge branch 'jk/check-docs-update' into maintLibravatar Junio C Hamano1-26/+9
* jk/check-docs-update: check-docs: get documented command list from Makefile check-docs: drop git-help special-case check-docs: list git-gui as a command check-docs: factor out command-list command-list: mention git-credential-* helpers command-list: add git-sh-i18n check-docs: update non-command documentation list check-docs: mention gitweb specially
2012-09-02test-regex: Add a test to check for a bug in the regex routinesLibravatar Ramsay Jones1-0/+1
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24Merge branch 'bw/maint-1.7.9-solaris-getpass' into maint-1.7.11Libravatar Junio C Hamano1-0/+1
* bw/maint-1.7.9-solaris-getpass: Enable HAVE_DEV_TTY for Solaris terminal: seek when switching between reading and writing
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-08check-docs: get documented command list from MakefileLibravatar Jeff King1-24/+2
The current code tries to get a list of documented commands by doing "ls Documentation/git*txt" and culling a bunch of special cases from the result. Looking for "git-*.txt" would be more accurate, but would miss a few commands like "gitweb" and "gitk". Fortunately, Documentation/Makefile already knows what this list is, so we can just ask it. Annoyingly, we still have to post-process its output a little, since make will print extra cruft like "GIT-VERSION-FILE is up to date" to stdout. Now that our list is accurate, we can remove all of the ugly special-cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08check-docs: drop git-help special-caseLibravatar Jeff King1-1/+0
The check-docs target special-cases git-help to avoid mentioning it as "documented but removed". This dates back to the early implementation of git-help, when its code was simply included inside git.c. These days it is a full-fledged builtin (in builtin/help.c) and does not need special-casing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08check-docs: list git-gui as a commandLibravatar Jeff King1-2/+1
git-gui is already documented and mentioned in command-list, but adding it to the Makefile makes sure it is so. We also add its alias git-citool (which is also documented). As a result, we can drop them from the special case statement that avoids them being listed as "documented but does not exist". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08check-docs: factor out command-listLibravatar Jeff King1-2/+6
The check-docs command list is composed from several Makefile variables plus some special cases. Let's make the meaning of the list more obvious and avoid repeating ourselves by factoring it out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08check-docs: update non-command documentation listLibravatar Jeff King1-0/+3
The check-docs target looks at Documentation/git*txt and complains if any entry does not have a matching command. Therefore we need to explicitly ignore any entries which are not meant to describe a command (like gitattributes.txt). This list has grown stale over time, so let's bring it up to date. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08check-docs: mention gitweb speciallyLibravatar Jeff King1-2/+2
Like gitk, gitweb is not listed in the usual Makefile variables and must be fed to check-docs specially. Otherwise check-docs thinks it is documented but removed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-06Merge branch 'jn/block-sha1' into maintLibravatar Junio C Hamano1-3/+2
* 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-08-06Merge branch 'jn/make-assembly-in-right-directory' into maintLibravatar Junio C Hamano1-1/+1
* jn/make-assembly-in-right-directory: Makefile: fix location of listing produced by "make subdir/foo.s"
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>