summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-11-06Merge branch 'md/exclude-promisor-objects-fix'Libravatar Junio C Hamano2-0/+8
Operations on promisor objects make sense in the context of only a small subset of the commands that internally use the revisions machinery, but the "--exclude-promisor-objects" option were taken and led to nonsense results by commands like "log", to which it didn't make much sense. This has been corrected. * md/exclude-promisor-objects-fix: exclude-promisor-objects: declare when option is allowed Documentation/git-log.txt: do not show --exclude-promisor-objects
2018-11-06Merge branch 'jt/upload-pack-v2-fix-shallow'Libravatar Junio C Hamano1-0/+25
"git fetch" over protocol v2 into a shallow repository failed to fetch full history behind a new tip of history that was diverged before the cut-off point of the history that was previously fetched shallowly. * jt/upload-pack-v2-fix-shallow: upload-pack: clear flags before each v2 request upload-pack: make want_obj not global upload-pack: make have_obj not global
2018-11-06Merge branch 'sb/submodule-url-to-absolute'Libravatar Junio C Hamano1-0/+24
Some codepaths failed to form a proper URL when .gitmodules record the URL to a submodule repository as relative to the repository of superproject, which has been corrected. * sb/submodule-url-to-absolute: submodule helper: convert relative URL to absolute URL if needed
2018-11-06Merge branch 'js/shallow-and-fetch-prune'Libravatar Junio C Hamano1-0/+27
"git repack" in a shallow clone did not correctly update the shallow points in the repository, leading to a repository that does not pass fsck. * js/shallow-and-fetch-prune: repack -ad: prune the list of shallow commits shallow: offer to prune only non-existing entries repack: point out a bug handling stale shallow info
2018-11-06Merge branch 'js/remote-archive-dwimfix'Libravatar Junio C Hamano2-1/+12
The logic to determine the archive type "git archive" uses did not correctly kick in for "git archive --remote", which has been corrected. * js/remote-archive-dwimfix: archive: initialize archivers earlier
2018-11-03Merge branch 'mg/gpg-fingerprint'Libravatar Junio C Hamano1-6/+12
New "--pretty=format:" placeholders %GF and %GP that show the GPG key fingerprints have been invented. * mg/gpg-fingerprint: gpg-interface.c: obtain primary key fingerprint as well gpg-interface.c: support getting key fingerprint via %GF format gpg-interface.c: use flags to determine key/signer info presence
2018-11-03Merge branch 'mg/gpg-parse-tighten'Libravatar Junio C Hamano1-0/+26
Detect and reject a signature block that has more than one GPG signature. * mg/gpg-parse-tighten: gpg-interface.c: detect and reject multiple signatures on commits
2018-11-03Merge branch 'en/merge-cleanup-more'Libravatar Junio C Hamano1-4/+4
Further clean-up of merge-recursive machinery. * en/merge-cleanup-more: merge-recursive: avoid showing conflicts with merge branch before HEAD merge-recursive: improve auto-merging messages with path collisions
2018-11-02Merge branch 'js/rebase-i-shortopt'Libravatar Junio C Hamano2-2/+4
"git rebase -i" learned to take 'b' as the short form of 'break' option in the todo list. * js/rebase-i-shortopt: rebase -i: recognize short commands without arguments
2018-11-02Merge branch 'js/rebase-i-break'Libravatar Junio C Hamano2-1/+10
"git rebase -i" learned a new insn, 'break', that the user can insert in the to-do list. Upon hitting it, the command returns control back to the user. * js/rebase-i-break: rebase -i: introduce the 'break' command rebase -i: clarify what happens on a failed `exec`
2018-11-02Merge branch 'js/rebase-autostash-fix'Libravatar Junio C Hamano1-0/+10
"git rebase" that has recently been rewritten in C had a few issues in its "--autstash" feature, which have been corrected. * js/rebase-autostash-fix: rebase --autostash: fix issue with dirty submodules rebase --autostash: demonstrate a problem with dirty submodules rebase (autostash): use an explicit OID to apply the stash rebase (autostash): store the full OID in <state-dir>/autostash rebase (autostash): avoid duplicate call to state_dir_path()
2018-11-02Merge branch 'ag/rebase-i-in-c'Libravatar Junio C Hamano1-0/+10
Rewrite of the remaining "rebase -i" machinery in C. * ag/rebase-i-in-c: rebase -i: move rebase--helper modes to rebase--interactive rebase -i: remove git-rebase--interactive.sh rebase--interactive2: rewrite the submodes of interactive rebase in C rebase -i: implement the main part of interactive rebase as a builtin rebase -i: rewrite init_basic_state() in C rebase -i: rewrite write_basic_state() in C rebase -i: rewrite the rest of init_revisions_and_shortrevisions() in C rebase -i: implement the logic to initialize $revisions in C rebase -i: remove unused modes and functions rebase -i: rewrite complete_action() in C t3404: todo list with commented-out commands only aborts sequencer: change the way skip_unnecessary_picks() returns its result sequencer: refactor append_todo_help() to write its message to a buffer rebase -i: rewrite checkout_onto() in C rebase -i: rewrite setup_reflog_action() in C sequencer: add a new function to silence a command, except if it fails rebase -i: rewrite the edit-todo functionality in C editor: add a function to launch the sequence editor rebase -i: rewrite append_todo_help() in C sequencer: make three functions and an enum from sequencer.c public
2018-10-30Merge branch 'ss/rename-tests'Libravatar Junio C Hamano7-147/+137
Reorganize some tests and rename them; "ls t/" now gives a better overview of what is tested for these scripts than before. * ss/rename-tests: t7501: rename commit test to comply with naming convention t7500: rename commit tests script to comply with naming convention t7502: rename commit test script to comply with naming convention t7509: cleanup description and filename t2000: rename and combine checkout clash tests
2018-10-30Merge branch 'jc/receive-deny-current-branch-fix'Libravatar Junio C Hamano1-1/+7
The receive.denyCurrentBranch=updateInstead codepath kicked in even when the push should have been rejected due to other reasons, such as it does not fast-forward or the update-hook rejects it, which has been corrected. * jc/receive-deny-current-branch-fix: receive: denyCurrentBranch=updateinstead should not blindly update
2018-10-30Merge branch 'js/diff-notice-has-drive-prefix'Libravatar Junio C Hamano1-0/+10
Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on Windows would strip initial parts from the paths because they were not recognized as absolute, which has been corrected. * js/diff-notice-has-drive-prefix: diff: don't attempt to strip prefix from absolute Windows paths
2018-10-30Merge branch 'rj/header-guards'Libravatar Junio C Hamano1-2/+2
Code clean-up. * rj/header-guards: headers: normalize the spelling of some header guards
2018-10-30Merge branch 'jk/test-tool-help'Libravatar Junio C Hamano1-2/+13
Developer support. * jk/test-tool-help: test-tool: show tool list on error
2018-10-30Merge branch 'js/pack-objects-mutex-init-fix'Libravatar Junio C Hamano1-0/+32
A mutex used in "git pack-objects" were not correctly initialized and this caused "git repack" to dump core on Windows. * js/pack-objects-mutex-init-fix: pack-objects (mingw): initialize `packing_data` mutex in the correct spot pack-objects (mingw): demonstrate a segmentation fault with large deltas pack-objects: fix typo 'detla' -> 'delta'
2018-10-30Merge branch 'jk/run-command-notdot'Libravatar Junio C Hamano1-1/+12
The implementation of run_command() API on the UNIX platforms had a bug that caused a command not on $PATH to be found in the current directory. * jk/run-command-notdot: run-command: mark path lookup errors with ENOENT
2018-10-30Merge branch 'tb/filter-alternate-refs'Libravatar Junio C Hamano1-1/+1
Test fix. * tb/filter-alternate-refs: t5410: use longer path for sample script Documentation/config.txt: fix typo in core.alternateRefsCommand
2018-10-30Merge branch 'lm/range-diff-submodule-fix'Libravatar Junio C Hamano1-0/+29
"git range-diff" did not work well when the compared ranges had changes in submodules and the "--submodule=log" was used. * lm/range-diff-submodule-fix: range-diff: allow to diff files regardless of submodule config
2018-10-30Merge branch 'md/filter-trees'Libravatar Junio C Hamano4-0/+190
The "rev-list --filter" feature learned to exclude all trees via "tree:0" filter. * md/filter-trees: list-objects: support for skipping tree traversal filter-trees: code clean-up of tests list-objects-filter: implement filter tree:0 list-objects-filter-options: do not over-strbuf_init list-objects-filter: use BUG rather than die revision: mark non-user-given objects instead rev-list: handle missing tree objects properly list-objects: always parse trees gently list-objects: refactor to process_tree_contents list-objects: store common func args in struct
2018-10-26Merge branch 'ld/p4-unshelve'Libravatar Junio C Hamano1-16/+59
"git p4 unshelve" improvements. * ld/p4-unshelve: git-p4: fully support unshelving changelists git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved git-p4: do not fail in verbose mode for missing 'fileSize' key
2018-10-26Merge branch 'np/log-graph-octopus-fix'Libravatar Junio C Hamano1-0/+102
"git log --graph" showing an octopus merge sometimes miscounted the number of display columns it is consuming to show the merge and its parent commits, which has been corrected. * np/log-graph-octopus-fix: log: fix coloring of certain octopus merge shapes
2018-10-26Merge branch 'sg/split-index-racefix'Libravatar Junio C Hamano2-21/+242
The codepath to support the experimental split-index mode had remaining "racily clean" issues fixed. * sg/split-index-racefix: split-index: BUG() when cache entry refers to non-existing shared entry split-index: smudge and add racily clean cache entries to split index split-index: don't compare cached data of entries already marked for split index split-index: count the number of deleted entries t1700-split-index: date back files to avoid racy situations split-index: add tests to demonstrate the racy split index problem t1700-split-index: document why FSMONITOR is disabled in this test script
2018-10-26Merge branch 'ma/t7005-bash-workaround'Libravatar Junio C Hamano1-1/+1
Test fix. * ma/t7005-bash-workaround: t7005-editor: quote filename to fix whitespace-issue
2018-10-26rebase -i: recognize short commands without argumentsLibravatar Johannes Sixt2-2/+4
The sequencer instruction 'b', short for 'break', is rejected: error: invalid line 2: b The reason is that the parser expects all short commands to have an argument. Permit short commands without arguments. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-26archive: initialize archivers earlierLibravatar Josh Steadmon2-1/+12
Initialize archivers as soon as possible when running git-archive. Various non-obvious behavior depends on having the archivers initialized, such as determining the desired archival format from the provided filename. Since 08716b3c11 ("archive: refactor file extension format-guessing", 2011-06-21), archive_format_from_filename() has used the registered archivers to match filenames (provided via --output) to archival formats. However, when git-archive is executed with --remote, format detection happens before the archivers have been registered. This causes archives from remotes to always be generated as TAR files, regardless of the actual filename (unless an explicit --format is provided). This patch fixes that behavior; archival format is determined properly from the output filename, even when --remote is used. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-25range-diff: allow to diff files regardless of submodule configLibravatar Lucas De Marchi1-0/+29
If we have `submodule.diff = log' in the configuration file or `--submodule=log' is given as argument, range-diff fails to compare both diffs and we only get the following output: Submodule a 0000000...0000000 (new submodule) Even if the repository doesn't have any submodule. That's because the mode in diff_filespec is not correct and when flushing the diff, down in builtin_diff() we will enter the condition: if (o->submodule_format == DIFF_SUBMODULE_LOG && (!one->mode || S_ISGITLINK(one->mode)) && (!two->mode || S_ISGITLINK(two->mode))) { show_submodule_summary(o, one->path ? one->path : two->path, &one->oid, &two->oid, two->dirty_submodule); return; It turns out that S_ISGITLINK will return true (mode == 0160000 here). Similar thing happens if submodule.diff is "diff". Do like it's done in grep.c when calling fill_filespec() and force it to be recognized as a file by adding S_IFREG to the mode. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-25repack -ad: prune the list of shallow commitsLibravatar Johannes Schindelin1-1/+1
`git repack` can drop unreachable commits without further warning, making the corresponding entries in `.git/shallow` invalid, which causes serious problems when deepening the branches. One scenario where unreachable commits are dropped by `git repack` is when a `git fetch --prune` (or even a `git fetch` when a ref was force-pushed in the meantime) can make a commit unreachable that was reachable before. Therefore it is not safe to assume that a `git repack -adlf` will keep unreachable commits alone (under the assumption that they had not been packed in the first place, which is an assumption at least some of Git's code seems to make). This is particularly important to keep in mind when looking at the `.git/shallow` file: if any commits listed in that file become unreachable, it is not a problem, but if they go missing, it *is* a problem. One symptom of this problem is that a deepening fetch may now fail with fatal: error in object: unshallow <commit-hash> To avoid this problem, let's prune the shallow list in `git repack` when the `-d` option is passed, unless `-A` is passed, too (which would force the now-unreachable objects to be turned into loose objects instead of being deleted). Additionally, we also need to take `--keep-reachable` and `--unpack-unreachable=<date>` into account. Note: an alternative solution discussed during the review of this patch was to teach `git fetch` to simply ignore entries in .git/shallow if the corresponding commits do not exist locally. A quick test, however, revealed that the .git/shallow file is written during a shallow *clone*, in which case the commits do not exist, either, but the "shallow" line *does* need to be sent. Therefore, this approach would be a lot more finicky than the approach presented by the this patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-25repack: point out a bug handling stale shallow infoLibravatar Johannes Schindelin1-0/+27
A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when we try to fetch with a larger `--depth` the next time, we may end up with: fatal: error in object: unshallow <commit-hash> Reported by Alejandro Pauly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-25t5410: use longer path for sample scriptLibravatar Jeff King1-1/+1
t5410 creates a sample script "alternate-refs", and sets core.alternateRefsCommand to just "alternate-refs". That shouldn't work, as "." is not in our $PATH, and so we should not find it. However, due to a bug in run-command.c, we sometimes find it anyway! Even more confusing, this bug is only in the fork-based version of run-command. So the test passes on Linux (etc), but fails on Windows. In preparation for fixing the run-command bug, let's use a more complete path here. Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-25t0061: adjust to test-tool transitionLibravatar Junio C Hamano1-1/+12
2018-10-25run-command: mark path lookup errors with ENOENTLibravatar Jeff King1-1/+12
Since commit e3a434468f (run-command: use the async-signal-safe execv instead of execvp, 2017-04-19), prepare_cmd() does its own PATH lookup for any commands we run (on non-Windows platforms). However, its logic does not match the old execvp call when we fail to find a matching entry in the PATH. Instead of feeding the name directly to execv, execvp would consider that an ENOENT error. By continuing and passing the name directly to execv, we effectively behave as if "." was included at the end of the PATH. This can have confusing and even dangerous results. The fix itself is pretty straight-forward. There's a new test in t0061 to cover this explicitly, and I've also added a duplicate of the ENOENT test to ensure that we return the correct errno for this case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24rebase --autostash: fix issue with dirty submodulesLibravatar Johannes Schindelin1-1/+1
Since we cannot stash dirty submodules, there is no use in requiring them to be clean (or stash them when they are not). This brings the built-in rebase in line with the previous, scripted version, which also did not care about dirty submodules (but it was admittedly not very easy to figure that out). This fixes https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24rebase --autostash: demonstrate a problem with dirty submodulesLibravatar Johannes Schindelin1-0/+10
It has been reported that dirty submodules cause problems with the built-in rebase when it is asked to autostash. The symptom is: fatal: Unexpected stash response: '' This patch adds a regression test that demonstrates that bug. Original report: https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23t7501: rename commit test to comply with naming conventionLibravatar Stephen P. Smith1-0/+0
The naming convention was documented [1] but this script was not renamed. The original commit message indicates the script tests basic commit functionality. Clean up the test name by changing the file name to specify the intent as documented in the initial commit. [1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15) Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23t7500: rename commit tests script to comply with naming conventionLibravatar Stephen P. Smith1-1/+1
When the test naming convention was documented[1] the commit script was not renamed. Update the test description to note that the tests fall into four general categories: template, sign-off, -F and squash tests. Chose to not add "File" to the new script name as that did not seem to convey the current test contents for that switch. [1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15) Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23t7502: rename commit test script to comply with naming conventionLibravatar Stephen P. Smith1-0/+0
When the test naming convention was documented[1] the commit script was not renamed. The test description for t7502 indicates that the test file is to contain porcelain type options for the commit command. The tests don't fall into a single category. There are tests for cleanup, sign-off, multiple message options, etc. Rename the t7502-commit.sh to t7502-commit-porcelain.sh which reflects the high level nature and usage of the options to commit. [1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15) Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23t7509: cleanup description and filenameLibravatar Stephen P. Smith1-1/+1
Rename test and update the test description to explicitly state that included tests all relate to commit authorship. The t7509-commit.sh file was not renamed when other scripts were updated in compliance with the test naming convention. [1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15) Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23t2000: rename and combine checkout clash testsLibravatar Stephen P. Smith3-145/+135
In an earlier patch some tests scripts were renamed and a naming convention was documented. [1] Merge t2000-checkout-cache-clash.sh and t2001-checkout-cache-clash.sh into t2000-conflict-when-checking-files-out.sh. [1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15) Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23exclude-promisor-objects: declare when option is allowedLibravatar Matthew DeVore2-0/+8
The --exclude-promisor-objects option causes some funny behavior in at least two commands: log and blame. It causes a BUG crash: $ git log --exclude-promisor-objects BUG: revision.c:2143: exclude_promisor_objects can only be used when fetch_if_missing is 0 Aborted [134] Fix this such that the option is treated like any other unknown option. The commands that must support it are limited, so declare in those commands that the flag is supported. In particular: pack-objects prune rev-list The commands were found by searching for logic which parses --exclude-promisor-objects outside of revision.c. Extra logic outside of revision.c is needed because fetch_if_missing must be turned on before revision.c sees the option or it will BUG-crash. The above list is supported by the fact that no other command is introspectively invoked by another command passing --exclude-promisor-object. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23gpg-interface.c: support getting key fingerprint via %GF formatLibravatar Michał Górny1-6/+12
Support processing VALIDSIG status that provides additional information for valid signatures. Use this information to propagate signing key fingerprint and expose it via %GF pretty format. This format can be used to build safer key verification systems that verify the key via complete fingerprint rather than short/long identifier provided by %GK. Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22gpg-interface.c: detect and reject multiple signatures on commitsLibravatar Michał Górny1-0/+26
GnuPG supports creating signatures consisting of multiple signature packets. If such a signature is verified, it outputs all the status messages for each signature separately. However, git currently does not account for such scenario and gets terribly confused over getting multiple *SIG statuses. For example, if a malicious party alters a signed commit and appends a new untrusted signature, git is going to ignore the original bad signature and report untrusted commit instead. However, %GK and %GS format strings may still expand to the data corresponding to the original signature, potentially tricking the scripts into trusting the malicious commit. Given that the use of multiple signatures is quite rare, git does not support creating them without jumping through a few hoops, and finally supporting them properly would require extensive API improvement, it seems reasonable to just reject them at the moment. Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22diff: don't attempt to strip prefix from absolute Windows pathsLibravatar Johannes Sixt1-0/+10
git diff can be invoked with absolute paths. Typically, this triggers the --no-index case. Then the absolute paths remain in the file names that are printed in the output. There is one peculiarity, though: When the command is invoked from a a sub-directory in a repository, then it is attempted to strip the sub-directory from the beginning of relative paths. Yet, to detect a relative path the code just checks for an initial forward slash. This mistakes a Windows style path like "D:/base" as a relative path and the output looks like this, for example: D:\dir\test\one>git -P diff --numstat D:\dir\base D:\dir\diff 1 1 ir/{base => diff}/1.txt where the correct output should be D:\dir\test\one>git -P diff --numstat D:\dir\base D:\dir\diff 1 1 D:/dir/{base => diff}/1.txt If the sub-directory where 'git diff' is invoked is sufficiently deep that the prefix becomes longer than the path to be printed, then the subsequent code accesses the path out of bounds. Use is_absolute_path() to detect Windows style absolute paths. One might wonder whether the check for a directory separator that is visible in the patch context should be changed from == '/' to is_dir_sep() or not. It turns out not to be necessary. That code only ever investigates paths that have undergone pathspec normalization, after which there are only forward slashes even on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19receive: denyCurrentBranch=updateinstead should not blindly updateLibravatar Junio C Hamano1-1/+7
The handling of receive.denyCurrentBranch=updateInstead was added to a switch statement that handles other values of the variable, but all the other case arms only checked a condition to reject the attempted push, or let later logic in the same function to still intervene, so that a push that does not fast-forward (which is checked after the switch statement in question) is still rejected. But the handling of updateInstead incorrectly took immediate effect, without giving other checks a chance to intervene. Instead of calling update_worktree() that causes the side effect immediately, just note the fact that we will need to call the function later, and first give other checks a chance to reject the request. After the update-hook gets a chance to reject the push (which happens as the last step in a series of checks), call update_worktree() when we earlier detected the need to. Reported-by: Rajesh Madamanchi Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19pack-objects (mingw): initialize `packing_data` mutex in the correct spotLibravatar Johannes Schindelin1-1/+1
In 9ac3f0e5b3e4 (pack-objects: fix performance issues on packing large deltas, 2018-07-22), a mutex was introduced that is used to guard the call to set the delta size. This commit even added code to initialize it, but at an incorrect spot: in `init_threaded_search()`, while the call to `oe_set_delta_size()` (and hence to `packing_data_lock()`) can happen in the call chain `check_object()` <- `get_object_details()` <- `prepare_pack()` <- `cmd_pack_objects()`, which is long before the `prepare_pack()` function calls `ll_find_deltas()` (which initializes the threaded search). Another tell-tale that the mutex was initialized in an incorrect spot is that the function to initialize it lives in builtin/, while the code that uses the mutex is defined in a libgit.a header file. Let's use a more appropriate function: `prepare_packing_data()`, which not only lives in libgit.a, but *has* to be called before the `packing_data` struct is used that contains that mutex. This fixes https://github.com/git-for-windows/git/issues/1839. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19pack-objects (mingw): demonstrate a segmentation fault with large deltasLibravatar Johannes Schindelin1-0/+32
There is a problem in the way 9ac3f0e5b3e4 (pack-objects: fix performance issues on packing large deltas, 2018-07-22) initializes that mutex in the `packing_data` struct. The problem manifests in a segmentation fault on Windows, when a mutex (AKA critical section) is accessed without being initialized. (With pthreads, you apparently do not really have to initialize them?) This was reported in https://github.com/git-for-windows/git/issues/1839. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19Merge branch 'jt/cache-tree-allow-missing-object-in-partial-clone'Libravatar Junio C Hamano1-0/+33
In a partial clone that will lazily be hydrated from the originating repository, we generally want to avoid "does this object exist (locally)?" on objects that we deliberately omitted when we created the clone. The cache-tree codepath (which is used to write a tree object out of the index) however insisted that the object exists, even for paths that are outside of the partial checkout area. The code has been updated to avoid such a check. * jt/cache-tree-allow-missing-object-in-partial-clone: cache-tree: skip some blob checks in partial clone
2018-10-19Merge branch 'tb/filter-alternate-refs'Libravatar Junio C Hamano1-0/+41
When pushing into a repository that borrows its objects from an alternate object store, "git receive-pack" that responds to the push request on the other side lists the tips of refs in the alternate to reduce the amount of objects transferred. This sometimes is detrimental when the number of refs in the alternate is absurdly large, in which case the bandwidth saved in potentially fewer objects transferred is wasted in excessively large ref advertisement. The alternate refs that are advertised are now configurable with a pair of configuration variables. * tb/filter-alternate-refs: transport.c: introduce core.alternateRefsPrefixes transport.c: introduce core.alternateRefsCommand transport.c: extract 'fill_alternate_refs_command' transport: drop refnames from for_each_alternate_ref