summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2014-06-25Merge branch 'nd/index-pack-one-fd-per-thread' into maintLibravatar Junio C Hamano1-7/+0
We used to disable threaded "git index-pack" on platforms without thread-safe pread(); use a different workaround for such platforms to allow threaded "git index-pack". * nd/index-pack-one-fd-per-thread: index-pack: work around thread-unsafe pread()
2014-04-30Revert the whole "ask curl-config" topic for nowLibravatar Junio C Hamano1-50/+14
Postpone this a bit during the feature freeze and retry the effort in the next cycle.
2014-04-28Merge branch 'db/make-with-curl'Libravatar Junio C Hamano1-13/+28
It turns out that some platforms do ship without curl-config even though they build with the hardcoded default -lcurl and rely on it to work. * db/make-with-curl: Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR
2014-04-28Makefile: default to -lcurl when no CURL_CONFIG or CURLDIRLibravatar Dave Borowitz1-13/+28
The original implementation of CURL_CONFIG support did not match the original behavior of using -lcurl when CURLDIR was not set. This broke implementations that were lacking curl-config but did have libcurl installed along system libraries, such as MSysGit. In other words, the assumption that curl-config is always installed was incorrect. Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due to curl-config being missing), use the old behavior of falling back to -lcurl. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-24Merge branch 'db/make-with-curl'Libravatar Junio C Hamano1-12/+33
Ask curl-config how to link with the curl library, instead of having only a limited configurability knobs in the Makefile. * db/make-with-curl: Makefile: allow static linking against libcurl Makefile: use curl-config to determine curl flags
2014-04-17i18n: only extract comments marked with "TRANSLATORS:"Libravatar Jiang Xin1-1/+1
When extract l10n messages, we use "--add-comments" option to keep comments right above the l10n messages for references. But sometimes irrelevant comments are also extracted. For example in the following code block, the comment in line 2 will be extracted as comment for the l10n message in line 3, but obviously it's wrong. { OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit, NULL /* takes no arguments */, N_("ignore paths removed in the working tree (same as --no-all)"), PARSE_OPT_NOARG, ignore_removal_cb }, Since almost all comments for l10n translators are marked with the same prefix (tag): "TRANSLATORS:", it's safe to only extract comments with this special tag. I.E. it's better to call xgettext as: xgettext --add-comments=TRANSLATORS: ... Also tweaks the multi-line comment in "init-db.c", to make it start with the proper tag, not "* TRANSLATORS:" (which has a star before the tag). Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-16index-pack: work around thread-unsafe pread()Libravatar Nguyễn Thái Ngọc Duy1-7/+0
Multi-threaing of index-pack was disabled with c0f8654 (index-pack: Disable threading on cygwin - 2012-06-26), because pread() implementations for Cygwin and MSYS were not thread safe. Recent Cygwin does offer usable pread() and we enabled multi-threading with 103d530f (Cygwin 1.7 has thread-safe pread, 2013-07-19). Work around this problem on platforms with a thread-unsafe pread() emulation by opening one file handle per thread; it would prevent parallel pread() on different file handles from stepping on each other. Also remove NO_THREAD_SAFE_PREAD that was introduced in c0f8654 because it's no longer used anywhere. This workaround is unconditional, even for platforms with thread-safe pread() because the overhead is small (a couple file handles more) and not worth fragmenting the code. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Tested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-15Makefile: allow static linking against libcurlLibravatar Dave Borowitz1-3/+13
This requires more flags than can be guessed with the old-style CURLDIR and related options, so is only supported when curl-config is present. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-15Makefile: use curl-config to determine curl flagsLibravatar Dave Borowitz1-12/+23
curl-config should always be installed alongside a curl distribution, and its purpose is to provide flags for building against libcurl, so use it instead of guessing flags and dependent libraries. Allow overriding CURL_CONFIG to a custom path to curl-config, to compile against a curl installation other than the first in PATH. Depending on the set of features curl is compiled with, there may be more libraries required than the previous two options of -lssl and -lidn. For example, with a vanilla build of libcurl-7.36.0 on Mac OS X 10.9: $ ~/d/curl-out-7.36.0/lib/curl-config --libs -L/Users/dborowitz/d/curl-out-7.36.0/lib -lcurl -lgssapi_krb5 -lresolv -lldap -lz Use this only when CURLDIR is not explicitly specified, to continue supporting older builds. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-08Merge branch 'jk/commit-dates-parsing-fix'Libravatar Junio C Hamano1-0/+8
Finishing touches for portability. * jk/commit-dates-parsing-fix: t4212: loosen far-in-future test for AIX date: recognize bogus FreeBSD gmtime output
2014-04-01date: recognize bogus FreeBSD gmtime outputLibravatar Jeff King1-0/+8
Most gmtime implementations return a NULL value when they encounter an error (and this behavior is specified by ANSI C and POSIX). FreeBSD's implementation, however, will simply leave the "struct tm" untouched. Let's also recognize this and convert it to a NULL (with this patch, t4212 should pass on FreeBSD). Reported-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'dp/makefile-charset-lib-doc'Libravatar Junio C Hamano1-2/+2
* dp/makefile-charset-lib-doc: Makefile: describe CHARSET_LIB better
2014-03-31comments: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-23Makefile: describe CHARSET_LIB betterLibravatar Дилян Палаузов1-2/+2
The original explanation was not even grammatically correct or readable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21Merge branch 'nd/tag-version-sort'Libravatar Junio C Hamano1-0/+1
Allow v1.9.0 sorted before v1.10.0 in "git tag --list" output. * nd/tag-version-sort: tag: support --sort=<spec>
2014-03-14Merge branch 'tg/index-v4-format'Libravatar Junio C Hamano1-0/+7
* tg/index-v4-format: read-cache: add index.version config variable test-lib: allow setting the index format version introduce GIT_INDEX_VERSION environment variable
2014-03-14Merge branch 'nd/no-more-fnmatch'Libravatar Junio C Hamano1-22/+0
We started using wildmatch() in place of fnmatch(3); complete the process and stop using fnmatch(3). * nd/no-more-fnmatch: actually remove compat fnmatch source code stop using fnmatch (either native or compat) Revert "test-wildmatch: add "perf" command to compare wildmatch and fnmatch" use wildmatch() directly without fnmatch() wrapper
2014-02-27tag: support --sort=<spec>Libravatar Nguyễn Thái Ngọc Duy1-0/+1
--sort=version:refname (or --sort=v:refname for short) sorts tags as if they are versions. --sort=-refname reverses the order (with or without ":version"). versioncmp() is copied from string/strverscmp.c in glibc commit ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding style. The implementation is under LGPL-2.1 and according to [1] I can relicense it to GPLv2. [1] http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-27Merge branch 'jk/pack-bitmap'Libravatar Junio C Hamano1-2/+14
Borrow the bitmap index into packfiles from JGit to speed up enumeration of objects involved in a commit range without having to fully traverse the history. * jk/pack-bitmap: (26 commits) ewah: unconditionally ntohll ewah data ewah: support platforms that require aligned reads read-cache: use get_be32 instead of hand-rolled ntoh_l block-sha1: factor out get_be and put_be wrappers do not discard revindex when re-preparing packfiles pack-bitmap: implement optional name_hash cache t/perf: add tests for pack bitmaps t: add basic bitmap functionality tests count-objects: recognize .bitmap in garbage-checking repack: consider bitmaps when performing repacks repack: handle optional files created by pack-objects repack: turn exts array into array-of-struct repack: stop using magic number for ARRAY_SIZE(exts) pack-objects: implement bitmap writing rev-list: add bitmap mode to speed up object lists pack-objects: use bitmaps when packing objects pack-objects: split add_object_entry pack-bitmap: add support for bitmap indexes documentation: add documentation for the bitmap format ewah: compressed bitmap implementation ...
2014-02-27Merge branch 'kb/fast-hashmap'Libravatar Junio C Hamano1-2/+3
Improvements to our hash table to get it to meet the needs of the msysgit fscache project, with some nice performance improvements. * kb/fast-hashmap: name-hash: retire unused index_name_exists() hashmap.h: use 'unsigned int' for hash-codes everywhere test-hashmap.c: drop unnecessary #includes .gitignore: test-hashmap is a generated file read-cache.c: fix memory leaks caused by removed cache entries builtin/update-index.c: cleanup update_one fix 'git update-index --verbose --again' output remove old hash.[ch] implementation name-hash.c: remove cache entries instead of marking them CE_UNHASHED name-hash.c: use new hash map implementation for cache entries name-hash.c: remove unreferenced directory entries name-hash.c: use new hash map implementation for directories diffcore-rename.c: use new hash map implementation diffcore-rename.c: simplify finding exact renames diffcore-rename.c: move code around to prepare for the next patch buitin/describe.c: use new hash map implementation add a hashtable implementation that supports O(1) removal submodule: don't access the .gitmodules cache entry after removing it
2014-02-24test-lib: allow setting the index format versionLibravatar Thomas Gummerer1-0/+7
Allow adding a TEST_GIT_INDEX_VERSION variable to config.mak to set the index version with which the test suite should be run. If it isn't set, the default version given in the source code is used (currently version 3). To avoid breakages with index versions other than [23], also set the index version under which t2104 is run to 3. This test only tests functionality specific to version 2 and 3 of the index file and would fail if the test suite is run with any other version. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-20stop using fnmatch (either native or compat)Libravatar Nguyễn Thái Ngọc Duy1-22/+0
Since v1.8.4 (about six months ago) wildmatch is used as default replacement for fnmatch. We have seen only one fix since so wildmatch probably has done a good job as fnmatch replacement. This concludes the fnmatch->wildmatch transition by no longer relying on fnmatch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'jk/revision-o-is-in-libgit-a'Libravatar Junio C Hamano1-2/+2
* jk/revision-o-is-in-libgit-a: Makefile: remove redundant object in git-http{fetch,push}
2014-01-27Makefile: remove redundant object in git-http{fetch,push}Libravatar John Keeping1-2/+2
revision.o is included in libgit.a which is in $(GITLIBS), so we don't need to include is separately. This fixes compilation with "-fwhole-program" which otherwise fails with messages like this: libgit.a(revision.o): In function `mark_tree_uninteresting': /home/john/src/git/revision.c:108: multiple definition of `mark_tree_uninteresting' /tmp/ccKQRkZV.ltrans2.ltrans.o:/home/john/src/git/revision.c:108: first defined here Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23Makefile: Fix compilation of Windows resource fileLibravatar Johannes Sixt1-1/+1
If the git version number consists of less than three period separated numbers, then the Windows resource file compilation issues a syntax error: $ touch git.rc $ make V=1 git.res GIT_VERSION = 1.9.rc0 windres -O coff \ -DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \ -DGIT_VERSION="\\\"1.9.rc0\\\"" git.rc -o git.res C:\msysgit\msysgit\mingw\bin\windres.exe: git.rc:2: syntax error make: *** [git.res] Error 1 $ Note that -DPATCH=rc0. The values passed via -DMAJOR=, -DMINOR=, and -DPATCH= are used in FILEVERSION and PRODUCTVERSION statements, which expect up to four numeric values. These version numbers are intended for machine consumption. They are typically inspected by installers to decide whether a file to be installed is newer than one that exists on the system, but are not used for much else. We can be pretty certain that there are no tools that look at these version numbers, not even the installer of Git for Windows does. Therefore, to fix the syntax error, fill in only the first two numbers, which we are guaranteed to find in Git version numbers. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30pack-objects: implement bitmap writingLibravatar Vicent Marti1-0/+1
This commit extends more the functionality of `pack-objects` by allowing it to write out a `.bitmap` index next to any written packs, together with the `.idx` index that currently gets written. If bitmap writing is enabled for a given repository (either by calling `pack-objects` with the `--write-bitmap-index` flag or by having `pack.writebitmaps` set to `true` in the config) and pack-objects is writing a packfile that would normally be indexed (i.e. not piping to stdout), we will attempt to write the corresponding bitmap index for the packfile. Bitmap index writing happens after the packfile and its index has been successfully written to disk (`finish_tmp_packfile`). The process is performed in several steps: 1. `bitmap_writer_set_checksum`: this call stores the partial checksum for the packfile being written; the checksum will be written in the resulting bitmap index to verify its integrity 2. `bitmap_writer_build_type_index`: this call uses the array of `struct object_entry` that has just been sorted when writing out the actual packfile index to disk to generate 4 type-index bitmaps (one for each object type). These bitmaps have their nth bit set if the given object is of the bitmap's type. E.g. the nth bit of the Commits bitmap will be 1 if the nth object in the packfile index is a commit. This is a very cheap operation because the bitmap writing code has access to the metadata stored in the `struct object_entry` array, and hence the real type for each object in the packfile. 3. `bitmap_writer_reuse_bitmaps`: if there exists an existing bitmap index for one of the packfiles we're trying to repack, this call will efficiently rebuild the existing bitmaps so they can be reused on the new index. All the existing bitmaps will be stored in a `reuse` hash table, and the commit selection phase will prioritize these when selecting, as they can be written directly to the new index without having to perform a revision walk to fill the bitmap. This can greatly speed up the repack of a repository that already has bitmaps. 4. `bitmap_writer_select_commits`: if bitmap writing is enabled for a given `pack-objects` run, the sequence of commits generated during the Counting Objects phase will be stored in an array. We then use that array to build up the list of selected commits. Writing a bitmap in the index for each object in the repository would be cost-prohibitive, so we use a simple heuristic to pick the commits that will be indexed with bitmaps. The current heuristics are a simplified version of JGit's original implementation. We select a higher density of commits depending on their age: the 100 most recent commits are always selected, after that we pick 1 commit of each 100, and the gap increases as the commits grow older. On top of that, we make sure that every single branch that has not been merged (all the tips that would be required from a clone) gets their own bitmap, and when selecting commits between a gap, we tend to prioritize the commit with the most parents. Do note that there is no right/wrong way to perform commit selection; different selection algorithms will result in different commits being selected, but there's no such thing as "missing a commit". The bitmap walker algorithm implemented in `prepare_bitmap_walk` is able to adapt to missing bitmaps by performing manual walks that complete the bitmap: the ideal selection algorithm, however, would select the commits that are more likely to be used as roots for a walk in the future (e.g. the tips of each branch, and so on) to ensure a bitmap for them is always available. 5. `bitmap_writer_build`: this is the computationally expensive part of bitmap generation. Based on the list of commits that were selected in the previous step, we perform several incremental walks to generate the bitmap for each commit. The walks begin from the oldest commit, and are built up incrementally for each branch. E.g. consider this dag where A, B, C, D, E, F are the selected commits, and a, b, c, e are a chunk of simplified history that will not receive bitmaps. A---a---B--b--C--c--D \ E--e--F We start by building the bitmap for A, using A as the root for a revision walk and marking all the objects that are reachable until the walk is over. Once this bitmap is stored, we reuse the bitmap walker to perform the walk for B, assuming that once we reach A again, the walk will be terminated because A has already been SEEN on the previous walk. This process is repeated for C, and D, but when we try to generate the bitmaps for E, we can reuse neither the current walk nor the bitmap we have generated so far. What we do now is resetting both the walk and clearing the bitmap, and performing the walk from scratch using E as the origin. This new walk, however, does not need to be completed. Once we hit B, we can lookup the bitmap we have already stored for that commit and OR it with the existing bitmap we've composed so far, allowing us to limit the walk early. After all the bitmaps have been generated, another iteration through the list of commits is performed to find the best XOR offsets for compression before writing them to disk. Because of the incremental nature of these bitmaps, XORing one of them with its predecesor results in a minimal "bitmap delta" most of the time. We can write this delta to the on-disk bitmap index, and then re-compose the original bitmaps by XORing them again when loaded. This is a phase very similar to pack-object's `find_delta` (using bitmaps instead of objects, of course), except the heuristics have been greatly simplified: we only check the 10 bitmaps before any given one to find best compressing one. This gives good results in practice, because there is locality in the ordering of the objects (and therefore bitmaps) in the packfile. 6. `bitmap_writer_finish`: the last step in the process is serializing to disk all the bitmap data that has been generated in the two previous steps. The bitmap is written to a tmp file and then moved atomically to its final destination, using the same process as `pack-write.c:write_idx_file`. Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30pack-bitmap: add support for bitmap indexesLibravatar Vicent Marti1-0/+2
A bitmap index is a `.bitmap` file that can be found inside `$GIT_DIR/objects/pack/`, next to its corresponding packfile, and contains precalculated reachability information for selected commits. The full specification of the format for these bitmap indexes can be found in `Documentation/technical/bitmap-format.txt`. For a given commit SHA1, if it happens to be available in the bitmap index, its bitmap will represent every single object that is reachable from the commit itself. The nth bit in the bitmap is the nth object in the packfile; if it's set to 1, the object is reachable. By using the bitmaps available in the index, this commit implements several new functions: - `prepare_bitmap_git` - `prepare_bitmap_walk` - `traverse_bitmap_commit_list` - `reuse_partial_packfile_from_bitmap` The `prepare_bitmap_walk` function tries to build a bitmap of all the objects that can be reached from the commit roots of a given `rev_info` struct by using the following algorithm: - If all the interesting commits for a revision walk are available in the index, the resulting reachability bitmap is the bitwise OR of all the individual bitmaps. - When the full set of WANTs is not available in the index, we perform a partial revision walk using the commits that don't have bitmaps as roots, and limiting the revision walk as soon as we reach a commit that has a corresponding bitmap. The earlier OR'ed bitmap with all the indexed commits can now be completed as this walk progresses, so the end result is the full reachability list. - For revision walks with a HAVEs set (a set of commits that are deemed uninteresting), first we perform the same method as for the WANTs, but using our HAVEs as roots, in order to obtain a full reachability bitmap of all the uninteresting commits. This bitmap then can be used to: a) limit the subsequent walk when building the WANTs bitmap b) finding the final set of interesting commits by performing an AND-NOT of the WANTs and the HAVEs. If `prepare_bitmap_walk` runs successfully, the resulting bitmap is stored and the equivalent of a `traverse_commit_list` call can be performed by using `traverse_bitmap_commit_list`; the bitmap version of this call yields the objects straight from the packfile index (without having to look them up or parse them) and hence is several orders of magnitude faster. As an extra optimization, when `prepare_bitmap_walk` succeeds, the `reuse_partial_packfile_from_bitmap` call can be attempted: it will find the amount of objects at the beginning of the on-disk packfile that can be reused as-is, and return an offset into the packfile. The source packfile can then be loaded and the bytes up to `offset` can be written directly to the result without having to consider the entires inside the packfile individually. If the `prepare_bitmap_walk` call fails (e.g. because no bitmap files are available), the `rev_info` struct is left untouched, and can be used to perform a manual rev-walk using `traverse_commit_list`. Hence, this new set of functions are a generic API that allows to perform the equivalent of git rev-list --objects [roots...] [^uninteresting...] for any set of commits, even if they don't have specific bitmaps generated for them. In further patches, we'll use this bitmap traversal optimization to speed up the `pack-objects` and `rev-list` commands. Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30ewah: compressed bitmap implementationLibravatar Vicent Marti1-2/+9
EWAH is a word-aligned compressed variant of a bitset (i.e. a data structure that acts as a 0-indexed boolean array for many entries). It uses a 64-bit run-length encoding (RLE) compression scheme, trading some compression for better processing speed. The goal of this word-aligned implementation is not to achieve the best compression, but rather to improve query processing time. As it stands right now, this EWAH implementation will always be more efficient storage-wise than its uncompressed alternative. EWAH arrays will be used as the on-disk format to store reachability bitmaps for all objects in a repository while keeping reasonable sizes, in the same way that JGit does. This EWAH implementation is a mostly straightforward port of the original `javaewah` library that JGit currently uses. The library is self-contained and has been embedded whole (4 files) inside the `ewah` folder to ease redistribution. The library is re-licensed under the GPLv2 with the permission of Daniel Lemire, the original author. The source code for the C version can be found on GitHub: https://github.com/vmg/libewok The original Java implementation can also be found on GitHub: https://github.com/lemire/javaewah [jc: stripped debug-only code per Peff's $gmane/239768] Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12Merge branch 'jk/remove-deprecated'Libravatar Junio C Hamano1-5/+1
* jk/remove-deprecated: stop installing git-tar-tree link peek-remote: remove deprecated alias of ls-remote lost-found: remove deprecated command tar-tree: remove deprecated command repo-config: remove deprecated alias for "git config"
2013-12-03stop installing git-tar-tree linkLibravatar Jonathan Nieder1-2/+1
When the built-in "git tar-tree" command (a thin wrapper around "git archive") was removed in 925ceccf (tar-tree: remove deprecated command, 2013-11-10), the build continued to install a non-functioning git-tar-tree command in gitexecdir by mistake: $ PATH=$(git --exec-path):$PATH $ git-tar-tree -h fatal: cannot handle tar-tree internally The list of links in gitexecdir is populated from BUILTIN_OBJS, which includes builtin/tar-tree.o to implement "git get-tar-commit-id". Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c to reflect its purpose and fix 'make install'. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Makefile: add PERLLIB_EXTRA variable that adds to default perl pathLibravatar Jonathan Nieder1-1/+4
Some platforms ship Perl modules used by git scripts outside the default perl path (e.g., on Mac OS X, Subversion's perl bindings live in a separate xcode perl path). Add an PERLLIB_EXTRA variable to hold a colon-separated list of extra directories to add to the perl path in git's scripts, as a convenience for packagers. Requested-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Makefile: rebuild perl scripts when perl paths changeLibravatar Jonathan Nieder1-2/+11
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18remove old hash.[ch] implementationLibravatar Karsten Blees1-2/+0
Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18add a hashtable implementation that supports O(1) removalLibravatar Karsten Blees1-0/+3
The existing hashtable implementation (in hash.[ch]) uses open addressing (i.e. resolve hash collisions by distributing entries across the table). Thus, removal is difficult to implement with less than O(n) complexity. Resolving collisions of entries with identical hashes (e.g. via chaining) is left to the client code. Add a hashtable implementation that supports O(1) removal and is slightly easier to use due to builtin entry chaining. Supports all basic operations init, free, get, add, remove and iteration. Also includes ready-to-use hash functions based on the public domain FNV-1 algorithm (http://www.isthe.com/chongo/tech/comp/fnv). The per-entry data structure (hashmap_entry) is piggybacked in front of the client's data structure to save memory. See test-hashmap.c for usage examples. The hashtable is resized by a factor of four when 80% full. With these settings, average memory consumption is about 2/3 of hash.[ch], and insertion is about twice as fast due to less frequent resizing. Lookups are also slightly faster, because entries are strictly confined to their bucket (i.e. no data of other buckets needs to be traversed). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12peek-remote: remove deprecated alias of ls-remoteLibravatar John Keeping1-1/+0
This has been deprecated since commit 87194d2 (Deprecate peek-remote, 2007-11-24), included in version 1.5.4. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12lost-found: remove deprecated commandLibravatar John Keeping1-1/+0
"git lost-found" has been deprecated since commit fc8b5f0 (Deprecate git-lost-found, 2007-11-08), included in version 1.5.4. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12repo-config: remove deprecated alias for "git config"Libravatar John Keeping1-1/+0
The release notes for Git 1.5.4 say that "git repo-config" will be removed in the next feature release. Since Git 2.0 is nearly here, remove it. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24pack-objects: refactor the packing listLibravatar Vicent Marti1-0/+2
The hash table that stores the packing list for a given `pack-objects` run was tightly coupled to the pack-objects code. In this commit, we refactor the hash table and the underlying storage array into a `packing_data` struct. The functionality for accessing and adding entries to the packing list is hence accessible from other parts of Git besides the `pack-objects` builtin. This refactoring is a requirement for further patches in this series that will require accessing the commit packing list from outside of `pack-objects`. The hash table implementation has been minimally altered: we now use table sizes which are always a power of two, to ensure a uniform index distribution in the array. Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18Merge branch 'sb/repack-in-c'Libravatar Junio C Hamano1-1/+1
Rewrite "git repack" in C. * sb/repack-in-c: repack: improve warnings about failure of renaming and removing files repack: retain the return value of pack-objects repack: rewrite the shell script in C
2013-10-14sparse: suppress some "using sizeof on a function" warningsLibravatar Ramsay Jones1-0/+3
Sparse issues an "using sizeof on a function" warning for each call to curl_easy_setopt() which sets an option that takes a function pointer parameter. (currently 12 such warnings over 4 files.) The warnings relate to the use of the "typecheck-gcc.h" header file which adds a layer of type-checking macros to the curl function invocations (for gcc >= 4.3 and !__cplusplus). As part of the type-checking layer, 'sizeof' is applied to the function parameter of curl_easy_setopt(). Note that, in the context of sizeof, the function to function pointer conversion is not performed and that sizeof(f) != sizeof(&f). A simple solution, therefore, would be to replace the function name in each such call to curl_easy_setopt() with an explicit function pointer expression (i.e. replace f with &f). However, the "typecheck-gcc.h" header file is only conditionally included, in addition to the gcc and C++ checks mentioned above, depending on the CURL_DISABLE_TYPECHECK preprocessor variable. In order to suppress the warnings, we use target-specific variable assignments to add -DCURL_DISABLE_TYPECHECK to SPARSE_FLAGS for each file affected (http-push.c, http.c, http-walker.c and remote-curl.c). Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-17repack: rewrite the shell script in CLibravatar Stefan Beller1-1/+1
The motivation of this patch is to get closer to a goal of being able to have a core subset of git functionality built in to git. That would mean * people on Windows could get a copy of at least the core parts of Git without having to install a Unix-style shell * people using git in on servers with chrooted environments do not need to worry about standard tools lacking for shell scripts. This patch is meant to be mostly a literal translation of the git-repack script; the intent is that later patches would start using more library facilities, but this patch is meant to be as close to a no-op as possible so it doesn't do that kind of thing. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'jk/remove-remote-helpers-in-python'Libravatar Junio C Hamano1-16/+0
Remove now disused remote-helpers framework for helpers written in Python. * jk/remove-remote-helpers-in-python: git_remote_helpers: remove little used Python library
2013-09-09Merge branch 'sp/clip-read-write-to-8mb'Libravatar Junio C Hamano1-8/+0
Send a large request to read(2)/write(2) as a smaller but still reasonably large chunks, which would improve the latency when the operation needs to be killed and incidentally works around broken 64-bit systems that cannot take a 2GB write or read in one go. * sp/clip-read-write-to-8mb: Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU" xread, xwrite: limit size of IO to 8MB
2013-09-09Merge branch 'jc/url-match'Libravatar Junio C Hamano1-0/+3
Allow section.<urlpattern>.var configuration variables to be treated as a "virtual" section.var given a URL, and use the mechanism to enhance http.* configuration variables. This is a reroll of Kyle J. McKay's work. * jc/url-match: builtin/config.c: compilation fix config: "git config --get-urlmatch" parses section.<url>.key builtin/config: refactor collect_config() config: parse http.<url>.<variable> using urlmatch config: add generic callback wrapper to parse section.<url>.key config: add helper to normalize and match URLs http.c: fix parsing of http.sslCertPasswordProtected variable
2013-09-09git_remote_helpers: remove little used Python libraryLibravatar John Keeping1-16/+0
When it was originally added, the git_remote_helpers library was used as part of the tests of the remote-helper interface, but since commit fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) a simple shell script is used for this. A search on Ohloh [1] indicates that this library isn't used by any external projects and even the Python remote helpers in contrib/ don't use this library, so it is only used by its own test suite. Since this is the only Python library in Git, removing it will make packaging easier as the Python scripts only need to be installed for one version of Python, whereas the library should be installed for all available versions. [1] http://code.ohloh.net/search?s=%22git_remote_helpers%22 Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04Merge branch 'da/darwin'Libravatar Junio C Hamano1-0/+3
* da/darwin: OS X: Fix redeclaration of die warning Makefile: Fix APPLE_COMMON_CRYPTO with BLK_SHA1 imap-send: use Apple's Security framework for base64 encoding
2013-08-20Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU"Libravatar Steffen Prohaska1-8/+0
This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3. The previous commit introduced a size limit on IO chunks on all platforms. The compat clipped_write() is not needed anymore. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05config: parse http.<url>.<variable> using urlmatchLibravatar Kyle J. McKay1-0/+3
Use the urlmatch_config_entry() to wrap the underlying http_options() two-level variable parser in order to set http.<variable> to the value with the most specific URL in the configuration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Makefile: Fix APPLE_COMMON_CRYPTO with BLK_SHA1Libravatar Brian Gernhardt1-1/+3
It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see 3ef2bca) so make sure that the appropriate libraries are always set. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>