summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-04-16ci: exercise the whole test suite with uncommon code in pack-objectsLibravatar Nguyễn Thái Ngọc Duy1-1/+4
Some recent optimizations have been added to pack-objects to reduce memory usage and some code paths are split into two: one for common use cases and one for rare ones. Make sure the rare cases are tested with Travis since it requires manual test configuration that is unlikely to be done by developers. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: reorder members to shrink struct object_entryLibravatar Nguyễn Thái Ngọc Duy1-7/+21
Previous patches leave lots of holes and padding in this struct. This patch reorders the members and shrinks the struct down to 80 bytes (from 136 bytes on 64-bit systems, before any field shrinking is done) with 16 bits to spare (and a couple more in in_pack_header_size when we really run out of bits). This is the last in a series of memory reduction patches (see "pack-objects: a bit of document about struct object_entry" for the first one). Overall they've reduced repack memory size on linux-2.6.git from 3.747G to 3.424G, or by around 320M, a decrease of 8.5%. The runtime of repack has stayed the same throughout this series. Ævar's testing on a big monorepo he has access to (bigger than linux-2.6.git) has shown a 7.9% reduction, so the overall expected improvement should be somewhere around 8%. See 87po42cwql.fsf@evledraar.gmail.com on-list (https://public-inbox.org/git/87po42cwql.fsf@evledraar.gmail.com/) for more detailed numbers and a test script used to produce the numbers cited above. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: shrink delta_size field in struct object_entryLibravatar Nguyễn Thái Ngọc Duy2-11/+38
Allowing a delta size of 64 bits is crazy. Shrink this field down to 20 bits with one overflow bit. If we find an existing delta larger than 1MB, we do not cache delta_size at all and will get the value from oe_size(), potentially from disk if it's larger than 4GB. Note, since DELTA_SIZE() is used in try_delta() code, it must be thread-safe. Luckily oe_size() does guarantee this so we it is thread-safe. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: shrink size field in struct object_entryLibravatar Nguyễn Thái Ngọc Duy4-26/+145
It's very very rare that an uncompressed object is larger than 4GB (partly because Git does not handle those large files very well to begin with). Let's optimize it for the common case where object size is smaller than this limit. Shrink size field down to 31 bits and one overflow bit. If the size is too large, we read it back from disk. As noted in the previous patch, we need to return the delta size instead of canonical size when the to-be-reused object entry type is a delta instead of a canonical one. Add two compare helpers that can take advantage of the overflow bit (e.g. if the file is 4GB+, chances are it's already larger than core.bigFileThreshold and there's no point in comparing the actual value). Another note about oe_get_size_slow(). This function MUST be thread safe because SIZE() macro is used inside try_delta() which may run in parallel. Outside parallel code, no-contention locking should be dirt cheap (or insignificant compared to i/o access anyway). To exercise this code, it's best to run the test suite with something like make test GIT_TEST_OE_SIZE=4 which forces this code on all objects larger than 3 bytes. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: clarify the use of object_entry::sizeLibravatar Nguyễn Thái Ngọc Duy2-4/+11
While this field most of the time contains the canonical object size, there is one case it does not: when we have found that the base object of the delta in question is also to be packed, we will very happily reuse the delta by copying it over instead of regenerating the new delta. "size" in this case will record the delta size, not canonical object size. Later on in write_reuse_object(), we reconstruct the delta header and "size" is used for this purpose. When this happens, the "type" field contains a delta type instead of a canonical type. Highlight this in the code since it could be tricky to see. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: don't check size when the object is badLibravatar Nguyễn Thái Ngọc Duy1-2/+2
sha1_object_info() in check_objects() may fail to locate an object in the pack and return type OBJ_BAD. In that case, it will likely leave the "size" field untouched. We delay error handling until later in prepare_pack() though. Until then, do not touch "size" field. This field should contain the default value zero, but we can't say sha1_object_info() cannot damage it. This becomes more important later when the object size may have to be retrieved back from the (non-existing) pack. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: shrink z_delta_size field in struct object_entryLibravatar Nguyễn Thái Ngọc Duy3-8/+22
We only cache deltas when it's smaller than a certain limit. This limit defaults to 1000 but save its compressed length in a 64-bit field. Shrink that field down to 20 bits, so you can only cache 1MB deltas. Larger deltas must be recomputed at when the pack is written down. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: refer to delta objects by index instead of pointerLibravatar Nguyễn Thái Ngọc Duy2-59/+125
These delta pointers always point to elements in the objects[] array in packing_data struct. We can only hold maximum 4G of those objects because the array size in nr_objects is uint32_t. We could use uint32_t indexes to address these elements instead of pointers. On 64-bit architecture (8 bytes per pointer) this would save 4 bytes per pointer. Convert these delta pointers to indexes. Since we need to handle NULL pointers as well, the index is shifted by one [1]. [1] This means we can only index 2^32-2 objects even though nr_objects could contain 2^32-1 objects. It should not be a problem in practice because when we grow objects[], nr_alloc would probably blow up long before nr_objects hits the wall. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: move in_pack out of struct object_entryLibravatar Nguyễn Thái Ngọc Duy6-12/+130
Instead of using 8 bytes (on 64 bit arch) to store a pointer to a pack. Use an index instead since the number of packs should be relatively small. This limits the number of packs we can handle to 1k. Since we can't be sure people can never run into the situation where they have more than 1k pack files. Provide a fall back route for it. If we find out they have too many packs, the new in_pack_by_idx[] array (which has at most 1k elements) will not be used. Instead we allocate in_pack[] array that holds nr_objects elements. This is similar to how the optional in_pack_pos field is handled. The new simple test is just to make sure the too-many-packs code path is at least executed. The true test is running make test GIT_TEST_FULL_IN_PACK_ARRAY=1 to take advantage of other special case tests. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: move in_pack_pos out of struct object_entryLibravatar Nguyễn Thái Ngọc Duy5-7/+26
This field is only need for pack-bitmap, which is an optional feature. Move it to a separate array that is only allocated when pack-bitmap is used (like objects[], it is not freed, since we need it until the end of the process) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: use bitfield for object_entry::depthLibravatar Nguyễn Thái Ngọc Duy5-5/+15
Because of struct packing from now on we can only handle max depth 4095 (or even lower when new booleans are added in this struct). This should be ok since long delta chain will cause significant slow down anyway. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: use bitfield for object_entry::dfs_stateLibravatar Nguyễn Thái Ngọc Duy2-11/+20
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: turn type and in_pack_type to bitfieldsLibravatar Nguyễn Thái Ngọc Duy5-30/+58
An extra field type_valid is added to carry the equivalent of OBJ_BAD in the original "type" field. in_pack_type always contains a valid type so we only need 3 bits for it. A note about accepting OBJ_NONE as "valid" type. The function read_object_list_from_stdin() can pass this value [1] and it eventually calls create_object_entry() where current code skip setting "type" field if the incoming type is zero. This does not have any bad side effects because "type" field should be memset()'d anyway. But since we also need to set type_valid now, skipping oe_set_type() leaves type_valid zero/false, which will make oe_type() return OBJ_BAD, not OBJ_NONE anymore. Apparently we do care about OBJ_NONE in prepare_pack(). This switch from OBJ_NONE to OBJ_BAD may trigger fatal: unable to get type of object ... Accepting OBJ_NONE [2] does sound wrong, but this is how it is has been for a very long time and I haven't time to dig in further. [1] See 5c49c11686 (pack-objects: better check_object() performances - 2007-04-16) [2] 21666f1aae (convert object type handling from a string to a number - 2007-02-26) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16pack-objects: a bit of document about struct object_entryLibravatar Nguyễn Thái Ngọc Duy1-0/+45
The role of this comment block becomes more important after we shuffle fields around to shrink this struct. It will be much harder to see what field is related to what. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16read-cache.c: make $GIT_TEST_SPLIT_INDEX booleanLibravatar Nguyễn Thái Ngọc Duy3-3/+14
While at there, document about this special mode when running the test suite. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-12Merge branch 'svn/authors-prog-2' of git://bogomips.org/git-svnLibravatar Junio C Hamano5-12/+57
* 'svn/authors-prog-2' of git://bogomips.org/git-svn: git-svn: allow empty email-address using authors-prog and authors-file git-svn: search --authors-prog in PATH too
2018-04-11Revert "Merge branch 'en/rename-directory-detection'"Libravatar Junio C Hamano9-5197/+115
This reverts commit e4bb62fa1eeee689744b413e29a50b4d1dae6886, reversing changes made to 468165c1d8a442994a825f3684528361727cd8c0. The topic appears to inflict severe regression in renaming merges, even though the promise of it was that it would improve them. We do not yet know which exact change in the topic was wrong, but in the meantime, let's play it safe and revert it out of 'master' before real Git-using projects are harmed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11The third batch for 2.18Libravatar Junio C Hamano1-0/+30
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11Merge branch 'eb/cred-helper-ignore-sigpipe'Libravatar Junio C Hamano1-0/+3
When credential helper exits very quickly without reading its input, it used to cause Git to die with SIGPIPE, which has been fixed. * eb/cred-helper-ignore-sigpipe: credential: ignore SIGPIPE when writing to credential helpers
2018-04-11Merge branch 'lv/tls-1.3'Libravatar Junio C Hamano2-0/+4
When built with more recent cURL, GIT_SSL_VERSION can now specify "tlsv1.3" as its value. * lv/tls-1.3: http: allow use of TLS 1.3
2018-04-11Merge branch 'pk/test-avoid-pipe-hiding-exit-status'Libravatar Junio C Hamano15-159/+179
Test cleanup. * pk/test-avoid-pipe-hiding-exit-status: test: avoid pipes in git related commands for test
2018-04-11Merge branch 'rs/status-with-removed-submodule'Libravatar Junio C Hamano2-2/+21
"git submodule status" misbehaved on a submodule that has been removed from the working tree. * rs/status-with-removed-submodule: submodule: check for NULL return of get_submodule_ref_store()
2018-04-11Merge branch 'nd/combined-test-helper'Libravatar Junio C Hamano121-542/+684
Small test-helper programs have been consolidated into a single binary. * nd/combined-test-helper: (36 commits) t/helper: merge test-write-cache into test-tool t/helper: merge test-wildmatch into test-tool t/helper: merge test-urlmatch-normalization into test-tool t/helper: merge test-subprocess into test-tool t/helper: merge test-submodule-config into test-tool t/helper: merge test-string-list into test-tool t/helper: merge test-strcmp-offset into test-tool t/helper: merge test-sigchain into test-tool t/helper: merge test-sha1-array into test-tool t/helper: merge test-scrap-cache-tree into test-tool t/helper: merge test-run-command into test-tool t/helper: merge test-revision-walking into test-tool t/helper: merge test-regex into test-tool t/helper: merge test-ref-store into test-tool t/helper: merge test-read-cache into test-tool t/helper: merge test-prio-queue into test-tool t/helper: merge test-path-utils into test-tool t/helper: merge test-online-cpus into test-tool t/helper: merge test-mktemp into test-tool t/helper: merge (unused) test-mergesort into test-tool ...
2018-04-11Merge branch 'sb/packfiles-in-repository'Libravatar Junio C Hamano17-67/+58
Refactoring of the internal global data structure continues. * sb/packfiles-in-repository: packfile: keep prepare_packed_git() private packfile: allow find_pack_entry to handle arbitrary repositories packfile: add repository argument to find_pack_entry packfile: allow reprepare_packed_git to handle arbitrary repositories packfile: allow prepare_packed_git to handle arbitrary repositories packfile: allow prepare_packed_git_one to handle arbitrary repositories packfile: add repository argument to reprepare_packed_git packfile: add repository argument to prepare_packed_git packfile: add repository argument to prepare_packed_git_one packfile: allow install_packed_git to handle arbitrary repositories packfile: allow rearrange_packed_git to handle arbitrary repositories packfile: allow prepare_packed_git_mru to handle arbitrary repositories
2018-04-11Merge branch 'sb/object-store'Libravatar Junio C Hamano39-233/+393
Refactoring the internal global data structure to make it possible to open multiple repositories, work with and then close them. Rerolled by Duy on top of a separate preliminary clean-up topic. The resulting structure of the topics looked very sensible. * sb/object-store: (27 commits) sha1_file: allow sha1_loose_object_info to handle arbitrary repositories sha1_file: allow map_sha1_file to handle arbitrary repositories sha1_file: allow map_sha1_file_1 to handle arbitrary repositories sha1_file: allow open_sha1_file to handle arbitrary repositories sha1_file: allow stat_sha1_file to handle arbitrary repositories sha1_file: allow sha1_file_name to handle arbitrary repositories sha1_file: add repository argument to sha1_loose_object_info sha1_file: add repository argument to map_sha1_file sha1_file: add repository argument to map_sha1_file_1 sha1_file: add repository argument to open_sha1_file sha1_file: add repository argument to stat_sha1_file sha1_file: add repository argument to sha1_file_name sha1_file: allow prepare_alt_odb to handle arbitrary repositories sha1_file: allow link_alt_odb_entries to handle arbitrary repositories sha1_file: add repository argument to prepare_alt_odb sha1_file: add repository argument to link_alt_odb_entries sha1_file: add repository argument to read_info_alternates sha1_file: add repository argument to link_alt_odb_entry sha1_file: add raw_object_store argument to alt_odb_usable pack: move approximate object count to object store ...
2018-04-11Merge branch 'jc/test-must-be-empty'Libravatar Junio C Hamano1-5/+2
Test helper update. * jc/test-must-be-empty: test_must_be_empty: simplify file existence check
2018-04-11Merge branch 'cc/perf-aggregate-sort'Libravatar Junio C Hamano1-5/+65
Perf-test update. * cc/perf-aggregate-sort: perf/aggregate: add --sort-by=regression option perf/aggregate: add display_dir()
2018-04-11Merge branch 'ab/doc-hash-brokenness'Libravatar Junio C Hamano1-8/+32
Doc updates. * ab/doc-hash-brokenness: doc hash-function-transition: clarify what SHAttered means doc hash-function-transition: clarify how older gits die on NewHash
2018-04-11Merge branch 'bc/hash-independent-tests'Libravatar Junio C Hamano9-82/+100
Tests that rely on the exact hardcoded values of object names have been updated in preparation for hash function migration. * bc/hash-independent-tests: t2107: abstract away SHA-1-specific constants t2101: abstract away SHA-1-specific constants t2101: modernize test style t2020: abstract away SHA-1 specific constants t1507: abstract away SHA-1-specific constants t1411: abstract away SHA-1-specific constants t1405: sort reflog entries in a hash-independent way t1300: abstract away SHA-1-specific constants t1304: abstract away SHA-1-specific constants t1011: abstract away SHA-1-specific constants
2018-04-11Merge branch 'ab/drop-contrib-examples'Libravatar Junio C Hamano27-8137/+20
* ab/drop-contrib-examples: Remove contrib/examples/*
2018-04-10The second batch for 2.18Libravatar Junio C Hamano1-0/+25
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10Merge branch 'ys/bisect-object-id-missing-conversion-fix'Libravatar Junio C Hamano1-2/+2
Code clean-up. * ys/bisect-object-id-missing-conversion-fix: bisect: use oid_to_hex() for converting object_id hashes to hex strings
2018-04-10Merge branch 'yk/filter-branch-non-committish-refs'Libravatar Junio C Hamano2-2/+26
when refs that do not point at committish are given, "git filter-branch" gave a misleading error messages. This has been corrected. * yk/filter-branch-non-committish-refs: filter-branch: fix errors caused by refs that point at non-committish
2018-04-10Merge branch 'nd/trace-with-env'Libravatar Junio C Hamano1-1/+1
Code cleanup. * nd/trace-with-env: run-command: use strbuf_addstr() for adding a string to a strbuf
2018-04-10Merge branch 'nd/parseopt-completion-more'Libravatar Junio C Hamano3-76/+127
The mechanism to use parse-options API to automate the command line completion continues to get extended and polished. * nd/parseopt-completion-more: completion: use __gitcomp_builtin in _git_cherry completion: use __gitcomp_builtin in _git_ls_tree completion: delete option-only completion commands completion: add --option completion for most builtin commands completion: factor out _git_xxx calling code completion: mention the oldest version we need to support git.c: add hidden option --list-parseopt-builtins git.c: move cmd_struct declaration up
2018-04-10Merge branch 'ds/bsearch-hash'Libravatar Junio C Hamano3-57/+42
Code to find the length to uniquely abbreviate object names based on packfile content, which is a relatively recent addtion, has been optimized to use the same fan-out table. * ds/bsearch-hash: sha1_name: use bsearch_pack() in unique_in_pack() sha1_name: use bsearch_pack() for abbreviations packfile: define and use bsearch_pack() sha1_name: convert struct min_abbrev_data to object_id
2018-04-10Merge branch 'ws/rebase-p'Libravatar Junio C Hamano4-214/+216
Code clean-up. * ws/rebase-p: rebase: remove merges_option and a blank line rebase: remove unused code paths from git_rebase__interactive__preserve_merges rebase: remove unused code paths from git_rebase__interactive rebase: add and use git_rebase__interactive__preserve_merges rebase: extract functions out of git_rebase__interactive rebase: reindent function git_rebase__interactive rebase: update invocation of rebase dot-sourced scripts rebase-interactive: simplify pick_on_preserving_merges
2018-04-10Merge branch 'jk/diff-highlight-graph-fix'Libravatar Junio C Hamano2-37/+129
"diff-highlight" filter (in contrib/) learned to undertand "git log --graph" output better. * jk/diff-highlight-graph-fix: diff-highlight: detect --graph by indent diff-highlight: use flush() helper consistently diff-highlight: test graphs with --color diff-highlight: test interleaved parallel lines of history diff-highlight: prefer "echo" to "cat" in tests diff-highlight: use test_tick in graph test diff-highlight: correct test graph diagram
2018-04-10Merge branch 'nd/remove-ignore-env-field'Libravatar Junio C Hamano7-65/+101
Code clean-up for the "repository" abstraction. * nd/remove-ignore-env-field: repository.h: add comment and clarify repo_set_gitdir repository: delete ignore_env member sha1_file.c: move delayed getenv(altdb) back to setup_git_env() repository.c: delete dead functions repository.c: move env-related setup code back to environment.c repository: initialize the_repository in main()
2018-04-10Merge branch 'ps/contains-id-error-message'Libravatar Junio C Hamano8-14/+125
"git tag --contains no-such-commit" gave a full list of options after giving an error message. * ps/contains-id-error-message: parse-options: do not show usage upon invalid option value
2018-04-10The first batch for 2.18 cycleLibravatar Junio C Hamano3-2/+69
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10Merge branch 'tg/stash-untracked-with-pathspec-fix'Libravatar Junio C Hamano2-6/+60
"git stash push -u -- <pathspec>" gave an unnecessary and confusing error message when there was no tracked files that match the <pathspec>, which has been fixed. * tg/stash-untracked-with-pathspec-fix: stash: drop superfluos pathspec parameter stash push -u: don't create empty stash stash push: avoid printing errors stash: fix nonsense pipeline
2018-04-10Merge branch 'nd/worktree-prune'Libravatar Junio C Hamano4-27/+24
The way "git worktree prune" worked internally has been simplified, by assuming how "git worktree move" moves an existing worktree to a different place. * nd/worktree-prune: worktree prune: improve prune logic when worktree is moved worktree: delete dead code gc.txt: more details about what gc does
2018-04-10Merge branch 'bc/object-id'Libravatar Junio C Hamano111-594/+609
Conversion from uchar[20] to struct object_id continues. * bc/object-id: (36 commits) convert: convert to struct object_id sha1_file: introduce a constant for max header length Convert lookup_replace_object to struct object_id sha1_file: convert read_sha1_file to struct object_id sha1_file: convert read_object_with_reference to object_id tree-walk: convert tree entry functions to object_id streaming: convert istream internals to struct object_id tree-walk: convert get_tree_entry_follow_symlinks internals to object_id builtin/notes: convert static functions to object_id builtin/fmt-merge-msg: convert remaining code to object_id sha1_file: convert sha1_object_info* to object_id Convert remaining callers of sha1_object_info_extended to object_id packfile: convert unpack_entry to struct object_id sha1_file: convert retry_bad_packed_offset to struct object_id sha1_file: convert assert_sha1_type to object_id builtin/mktree: convert to struct object_id streaming: convert open_istream to use struct object_id sha1_file: convert check_sha1_signature to struct object_id sha1_file: convert read_loose_object to use struct object_id builtin/index-pack: convert struct ref_delta_entry to object_id ...
2018-04-10Merge branch 'ma/shortlog-revparse'Libravatar Junio C Hamano3-2/+13
"git shortlog cruft" aborted with a BUG message when run outside a Git repository. The command has been taught to complain about extra and unwanted arguments on its command line instead in such a case. * ma/shortlog-revparse: shortlog: disallow left-over arguments outside repo shortlog: add usage-string for stdin-reading git-shortlog.txt: reorder usages
2018-04-10Merge branch 'ab/install-symlinks'Libravatar Junio C Hamano1-17/+35
The build procedure learned to optionally use symbolic links (instead of hardlinks and copies) to install "git-foo" for built-in commands, whose binaries are all identical. * ab/install-symlinks: Makefile: optionally symlink libexec/git-core binaries to bin/git Makefile: add a gitexecdir_relative variable Makefile: fix broken bindir_relative variable
2018-04-10Merge branch 'ml/filter-branch-no-op-error'Libravatar Junio C Hamano2-1/+9
"git filter-branch" learned to use a different exit code to allow the callers to tell the case where there was no new commits to rewrite from other error cases. * ml/filter-branch-no-op-error: filter-branch: return 2 when nothing to rewrite
2018-04-10Merge branch 'ab/pcre-v2'Libravatar Junio C Hamano2-24/+28
Git can be built to use either v1 or v2 of the PCRE library, and so far, the build-time configuration USE_LIBPCRE=YesPlease instructed the build procedure to use v1, but now it means v2. USE_LIBPCRE1 and USE_LIBPCRE2 can be used to explicitly choose which version to use, as before. * ab/pcre-v2: Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1 configure: detect redundant --with-libpcre & --with-libpcre1 configure: fix a regression in PCRE v1 detection
2018-04-10Merge branch 'ti/fetch-everything-local-optim'Libravatar Junio C Hamano3-3/+47
A "git fetch" from a repository with insane number of refs into a repository that is already up-to-date still wasted too many cycles making many lstat(2) calls to see if these objects at the tips exist as loose objects locally. These lstat(2) calls are optimized away by enumerating all loose objects beforehand. It is unknown if the new strategy negatively affects existing use cases, fetching into a repository with many loose objects from a repository with small number of refs. * ti/fetch-everything-local-optim: fetch-pack.c: use oidset to check existence of loose object
2018-04-10Merge branch 'en/rename-directory-detection'Libravatar Junio C Hamano9-115/+5197
Rename detection logic in "diff" family that is used in "merge" has learned to guess when all of x/a, x/b and x/c have moved to z/a, z/b and z/c, it is likely that x/d added in the meantime would also want to move to z/d by taking the hint that the entire directory 'x' moved to 'z'. A bug causing dirty files involved in a rename to be overwritten during merge has also been fixed as part of this work. * en/rename-directory-detection: (29 commits) merge-recursive: ensure we write updates for directory-renamed file merge-recursive: avoid spurious rename/rename conflict from dir renames directory rename detection: new testcases showcasing a pair of bugs merge-recursive: fix remaining directory rename + dirty overwrite cases merge-recursive: fix overwriting dirty files involved in renames merge-recursive: avoid clobbering untracked files with directory renames merge-recursive: apply necessary modifications for directory renames merge-recursive: when comparing files, don't include trees merge-recursive: check for file level conflicts then get new name merge-recursive: add computation of collisions due to dir rename & merging merge-recursive: check for directory level conflicts merge-recursive: add get_directory_renames() merge-recursive: make a helper function for cleanup for handle_renames merge-recursive: split out code for determining diff_filepairs merge-recursive: make !o->detect_rename codepath more obvious merge-recursive: fix leaks of allocated renames and diff_filepairs merge-recursive: introduce new functions to handle rename logic merge-recursive: move the get_renames() function directory rename detection: tests for handling overwriting dirty files directory rename detection: tests for handling overwriting untracked files ...