summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-03-07t5503: fix overspecification of trace expectationLibravatar Jonathan Tan1-1/+1
In order to extract the wants from a trace, a loop in t5503 currently breaks if "0000" is found. This works for protocol v0 and v1, but not v2. Instead, teach t5503 to look specifically for the "want" string, which is compatible with all protocols. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07tests: always test fetch of unreachable with v0Libravatar Jonathan Tan4-9/+32
Some tests check that fetching an unreachable object fails, but protocol v2 allows such fetches. Unset GIT_TEST_PROTOCOL_VERSION so that these tests are always run using protocol v0. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07t5601: check ssh command only with protocol v0Libravatar Jonathan Tan1-8/+8
When running the SSH command as part of a fetch, Git will write "SendEnv GIT_PROTOCOL" as an option if protocol v1 or v2 is used, but not v0. Update all tests that check this to run Git with GIT_TEST_PROTOCOL_VERSION=0. I chose not to do a more thorough fix (for example, checking the value of GIT_TEST_PROTOCOL_VERSION to see if the SendEnv check needs to be done) because a set of patches [1] that unifies the handling of SSH options, including writing "SendEnv GIT_PROTOCOL" regardless of protocol version, is in progress. When that is done, this patch should be reverted, since the functionality in here is no longer needed. As of this patch, all tests pass if GIT_TEST_PROTOCOL_VERSION is set to 1. [1] https://public-inbox.org/git/cover.1545342797.git.steadmon@google.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07tests: define GIT_TEST_PROTOCOL_VERSIONLibravatar Jonathan Tan3-2/+6
Define a GIT_TEST_PROTOCOL_VERSION environment variable meant to be used from tests. When set, this ensures protocol.version is at least the given value, allowing the entire test suite to be run as if this configuration is in place for all repositories. As of this patch, all tests pass whether GIT_TEST_PROTOCOL_VERSION is unset or set to 0. Some tests fail when GIT_TEST_PROTOCOL_VERSION is set to 1 or 2, but this will be dealt with in subsequent patches. This is based on work by Ævar Arnfjörð Bjarmason. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'pw/no-editor-in-rebase-i-implicit'Libravatar Junio C Hamano3-6/+11
When GIT_SEQUENCE_EDITOR is set, the command was incorrectly started when modes of "git rebase" that implicitly uses the machinery for the interactive rebase are run, which has been corrected. * pw/no-editor-in-rebase-i-implicit: implicit interactive rebase: don't run sequence editor
2019-02-05Merge branch 'jk/diff-cc-stat-fixes'Libravatar Junio C Hamano6-23/+133
"git diff --color-moved --cc --stat -p" did not work well due to funny interaction between a bug in color-moved and the rest, which has been fixed. * jk/diff-cc-stat-fixes: combine-diff: treat --dirstat like --stat combine-diff: treat --summary like --stat combine-diff: treat --shortstat like --stat combine-diff: factor out stat-format mask diff: clear emitted_symbols flag after use t4006: resurrect commented-out tests
2019-02-05Merge branch 'bp/checkout-new-branch-optim'Libravatar Junio C Hamano1-0/+9
"git checkout -b <new> [HEAD]" to create a new branch from the current commit and check it out ought to be a no-op in the index and the working tree in normal cases, but there are corner cases that do require updates to the index and the working tree. Running it immediately after "git clone --no-checkout" is one of these cases that an earlier optimization kicked in incorrectly, which has been fixed. * bp/checkout-new-branch-optim: checkout: fix regression in checkout -b on intitial checkout checkout: add test demonstrating regression with checkout -b on initial commit
2019-02-05Merge branch 'jk/attr-macro-fix'Libravatar Junio C Hamano1-0/+20
Asking "git check-attr" about a macro (e.g. "binary") on a specific path did not work correctly, even though "git check-attr -a" listed such a macro correctly. This has been corrected. * jk/attr-macro-fix: attr: do not mark queried macros as unset
2019-02-05Merge branch 'js/test-git-installed'Libravatar Junio C Hamano1-1/+1
Test fix for Windows. * js/test-git-installed: tests: explicitly use `test-tool.exe` on Windows
2019-02-05Merge branch 'js/abspath-part-inside-repo'Libravatar Junio C Hamano1-0/+7
On a case-insensitive filesystem, we failed to compare the part of the path that is above the worktree directory in an absolute pathname, which has been corrected. * js/abspath-part-inside-repo: abspath_part_inside_repo: respect core.ignoreCase
2019-02-05Merge branch 'jt/namespaced-ls-refs-fix'Libravatar Junio C Hamano1-0/+21
Fix namespace support in protocol v2. * jt/namespaced-ls-refs-fix: ls-refs: filter refs using namespace-stripped name
2019-02-05Merge branch 'ab/commit-graph-write-progress'Libravatar Junio C Hamano1-7/+7
The codepath to show progress meter while writing out commit-graph file has been improved. * ab/commit-graph-write-progress: commit-graph write: emit a percentage for all progress commit-graph write: add itermediate progress commit-graph write: remove empty line for readability commit-graph write: add more descriptive progress output commit-graph write: show progress for object search commit-graph write: more descriptive "writing out" output commit-graph write: add "Writing out" progress output commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily commit-graph: rename "large edges" to "extra edges"
2019-02-05Merge branch 'js/t6042-timing-fix'Libravatar Junio C Hamano1-2/+2
Test update. * js/t6042-timing-fix: t6042: work around speed optimization on Windows
2019-02-05Merge branch 'jk/add-ignore-errors-bit-assignment-fix'Libravatar Junio C Hamano1-0/+9
"git add --ignore-errors" did not work as advertised and instead worked as an unintended synonym for "git add --renormalize", which has been fixed. * jk/add-ignore-errors-bit-assignment-fix: add: use separate ADD_CACHE_RENORMALIZE flag
2019-02-05Merge branch 'js/mingw-unc-path-w-backslashes'Libravatar Junio C Hamano2-0/+15
In Git for Windows, "git clone \\server\share\path" etc. that uses UNC paths from command line had bad interaction with its shell emulation. * js/mingw-unc-path-w-backslashes: mingw: special-case arguments to `sh` mingw (t5580): document bug when cloning from backslashed UNC paths
2019-02-05Merge branch 'cc/test-ref-store-typofix'Libravatar Junio C Hamano1-1/+1
An obvious typo in an assertion error message has been fixed. * cc/test-ref-store-typofix: helper/test-ref-store: fix "new-sha1" vs "old-sha1" typo
2019-02-05Merge branch 'jt/fetch-v2-sideband'Libravatar Junio C Hamano6-6/+13
"git fetch" and "git upload-pack" learned to send all exchange over the sideband channel while talking the v2 protocol. * jt/fetch-v2-sideband: tests: define GIT_TEST_SIDEBAND_ALL {fetch,upload}-pack: sideband v2 fetch response sideband: reverse its dependency on pkt-line pkt-line: introduce struct packet_writer pack-protocol.txt: accept error packets in any context Use packet_reader instead of packet_read_line
2019-02-05Merge branch 'js/commit-graph-chunk-table-fix'Libravatar Junio C Hamano1-3/+13
The codepath to read from the commit-graph file attempted to read past the end of it when the file's table-of-contents was corrupt. * js/commit-graph-chunk-table-fix: Makefile: correct example fuzz build commit-graph: fix buffer read-overflow commit-graph, fuzz: add fuzzer for commit-graph
2019-02-05Merge branch 'ld/git-p4-shelve-update-fix'Libravatar Junio C Hamano1-3/+54
"git p4" failed to update a shelved change when there were moved files, which has been corrected. * ld/git-p4-shelve-update-fix: git-p4: handle update of moved/copied files when updating a shelve git-p4: add failing test for shelved CL update involving move/copy
2019-02-05Merge branch 'js/filter-options-should-use-plain-int'Libravatar Junio C Hamano1-1/+138
Update the protocol message specification to allow only the limited use of scaled quantities. This is ensure potential compatibility issues will not go out of hand. * js/filter-options-should-use-plain-int: filter-options: expand scaled numbers tree:<depth>: skip some trees even when collecting omits list-objects-filter: teach tree:# how to handle >0
2019-02-05Merge branch 'sb/more-repo-in-api'Libravatar Junio C Hamano1-0/+10
The in-core repository instances are passed through more codepaths. * sb/more-repo-in-api: (23 commits) t/helper/test-repository: celebrate independence from the_repository path.h: make REPO_GIT_PATH_FUNC repository agnostic commit: prepare free_commit_buffer and release_commit_memory for any repo commit-graph: convert remaining functions to handle any repo submodule: don't add submodule as odb for push submodule: use submodule repos for object lookup pretty: prepare format_commit_message to handle arbitrary repositories commit: prepare logmsg_reencode to handle arbitrary repositories commit: prepare repo_unuse_commit_buffer to handle any repo commit: prepare get_commit_buffer to handle any repo commit-reach: prepare in_merge_bases[_many] to handle any repo commit-reach: prepare get_merge_bases to handle any repo commit-reach.c: allow get_merge_bases_many_0 to handle any repo commit-reach.c: allow remove_redundant to handle any repo commit-reach.c: allow merge_bases_many to handle any repo commit-reach.c: allow paint_down_to_common to handle any repo commit: allow parse_commit* to handle any repo object: parse_object to honor its repository argument object-store: prepare has_{sha1, object}_file to handle any repo object-store: prepare read_object_file to deal with any repo ...
2019-01-29Merge branch 'it/log-format-source'Libravatar Junio C Hamano2-0/+54
Custom userformat "log --format" learned %S atom that stands for the tip the traversal reached the commit from, i.e. --source. * it/log-format-source: log: add %S option (like --source) to log --format
2019-01-29Merge branch 'jt/upload-pack-deepen-relative-proto-v2'Libravatar Junio C Hamano1-0/+47
"git fetch --deepen=<more>" has been corrected to work over v2 protocol. * jt/upload-pack-deepen-relative-proto-v2: upload-pack: teach deepen-relative in protocol v2 fetch-pack: do not take shallow lock unnecessarily
2019-01-29Merge branch 'ms/http-no-more-failonerror'Libravatar Junio C Hamano2-0/+29
Debugging help for http transport. * ms/http-no-more-failonerror: test: test GIT_CURL_VERBOSE=1 shows an error remote-curl: unset CURLOPT_FAILONERROR remote-curl: define struct for CURLOPT_WRITEFUNCTION http: enable keep_error for HTTP requests http: support file handles for HTTP_KEEP_ERROR
2019-01-29Merge branch 'os/rebase-runs-post-checkout-hook'Libravatar Junio C Hamano1-54/+42
"git rebase" internally runs "checkout" to switch between branches, and the command used to call the post-checkout hook, but the reimplementation stopped doing so, which is getting fixed. * os/rebase-runs-post-checkout-hook: rebase: run post-checkout hook on checkout t5403: simplify by using a single repository
2019-01-29Merge branch 'bc/sha-256'Libravatar Junio C Hamano7-51/+188
Add sha-256 hash and plug it through the code to allow building Git with the "NewHash". * bc/sha-256: hash: add an SHA-256 implementation using OpenSSL sha256: add an SHA-256 implementation using libgcrypt Add a base implementation of SHA-256 support commit-graph: convert to using the_hash_algo t/helper: add a test helper to compute hash speed sha1-file: add a constant for hash block size t: make the sha1 test-tool helper generic t: add basic tests for our SHA-1 implementation cache: make hashcmp and hasheq work with larger hashes hex: introduce functions to print arbitrary hashes sha1-file: provide functions to look up hash algorithms sha1-file: rename algorithm to "sha1"
2019-01-29Merge branch 'sb/submodule-recursive-fetch-gets-the-tip'Libravatar Junio C Hamano2-3/+122
"git fetch --recurse-submodules" may not fetch the necessary commit that is bound to the superproject, which is getting corrected. * sb/submodule-recursive-fetch-gets-the-tip: fetch: ensure submodule objects fetched submodule.c: fetch in submodules git directory instead of in worktree submodule: migrate get_next_submodule to use repository structs repository: repo_submodule_init to take a submodule struct submodule: store OIDs in changed_submodule_names submodule.c: tighten scope of changed_submodule_names struct submodule.c: sort changed_submodule_names before searching it submodule.c: fix indentation sha1-array: provide oid_array_filter
2019-01-29Merge branch 'jt/fetch-pack-v2'Libravatar Junio C Hamano1-7/+15
"git fetch-pack" now can talk the version 2 protocol. * jt/fetch-pack-v2: fetch-pack: support protocol version 2
2019-01-29Merge branch 'jk/proto-v2-hidden-refs-fix'Libravatar Junio C Hamano1-0/+6
The v2 upload-pack protocol implementation failed to honor hidden-ref configuration, which has been corrected. An earlier attempt reverted out of 'next'. * jk/proto-v2-hidden-refs-fix: upload-pack: support hidden refs with protocol v2
2019-01-29Merge branch 'pw/diff-color-moved-ws-fix'Libravatar Junio C Hamano1-3/+96
"git diff --color-moved-ws" updates. * pw/diff-color-moved-ws-fix: diff --color-moved-ws: handle blank lines diff --color-moved-ws: modify allow-indentation-change diff --color-moved-ws: optimize allow-indentation-change diff --color-moved=zebra: be stricter with color alternation diff --color-moved-ws: fix false positives diff --color-moved-ws: demonstrate false positives diff: allow --no-color-moved-ws Use "whitespace" consistently diff: document --no-color-moved
2019-01-29Merge branch 'js/rebase-i-redo-exec'Libravatar Junio C Hamano1-0/+14
"git rebase -i" learned to re-execute a command given with 'exec' to run after it failed the last time. * js/rebase-i-redo-exec: rebase: introduce a shortcut for --reschedule-failed-exec rebase: add a config option to default to --reschedule-failed-exec rebase: introduce --reschedule-failed-exec
2019-01-28implicit interactive rebase: don't run sequence editorLibravatar Phillip Wood3-6/+11
If GIT_SEQUENCE_EDITOR is set then rebase runs it when executing implicit interactive rebases which are supposed to appear non-interactive to the user. Fix this by setting GIT_SEQUENCE_EDITOR=: rather than GIT_EDITOR=:. A couple of tests relied on the old behavior so they are updated to work with the new regime. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --dirstat like --statLibravatar Jeff King2-0/+4
Currently "--cc --dirstat" will show nothing for a merge. Like --shortstat and --summary in the previous two patches, it probably makes sense to treat it like we do --stat, and show a stat against the first-parent. This case is less obviously correct than for --shortstat and --summary, as those are basically variants of --stat themselves. It's possible we could develop a multi-parent combined dirstat format, in which case we might regret defining this first-parent behavior. But the same could be said for --stat, and in the 12+ years of it showing first-parent stats, nobody has complained. So showing the first-parent dirstat is at least _useful_, and if we later develop a clever multi-parent stat format, we'd probably have to deal with --stat anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --summary like --statLibravatar Jeff King2-0/+13
Currently "--cc --summary" on a merge shows nothing. Since we show "--cc --stat" as a stat against the first parent, and because --summary is typically used in combination with --stat, it makes sense to treat them both the same way. Note that we have to tweak t4013's setup a bit to test this case, as the existing merges do not have any --summary results against their first parent. But since the merge at the tip of 'master' does add and remove files with respect to the second parent, we can just make a reversed doppelganger merge where the parents are swapped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --shortstat like --statLibravatar Jeff King2-0/+5
The --stat of a combined diff is defined as the first-parent stat, going all the way back to 965f803c32 (combine-diff: show diffstat with the first parent., 2006-04-17). Naturally, we gave --numstat the same treatment in 74e2abe5b7 (diff --numstat, 2006-10-12). But --shortstat, which is really just the final line of --stat, does nothing, which produces confusing results: $ git show --oneline --stat eab7584e37 eab7584e37 Merge branch 'en/show-ref-doc-fix' Documentation/git-show-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git show --oneline --shortstat eab7584e37 eab7584e37 Merge branch 'en/show-ref-doc-fix' [nothing! We'd expect to see the "1 file changed..." line] This patch teaches combine-diff to treats the two formats identically. Reported-by: David Turner <novalis@novalis.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24diff: clear emitted_symbols flag after useLibravatar Jeff King1-0/+79
There's an odd bug when "log --color-moved" is used with the combination of "--cc --stat -p": the stat for merge commits is erroneously shown with the diff of the _next_ commit. The included test demonstrates the issue. Our history looks something like this: A-B-M--D \ / C When we run "git log --cc --stat -p --color-moved" starting at D, we get this sequence of events: 1. The diff for D is using -p, so diff_flush() calls into diff_flush_patch_all_file_pairs(). There we see that o->color_moved is in effect, so we point o->emitted_symbols to a static local struct, causing diff_flush_patch() to queue the symbols instead of actually writing them out. We then do our move detection, emit the symbols, and clear the struct. But we leave o->emitted_symbols pointing to our struct. 2. Next we compute the diff for M. This is a merge, so we use the combined diff code. In find_paths_generic(), we compute the pairwise diff between each commit and its parent. Normally this is done with DIFF_FORMAT_NO_OUTPUT, since we're just looking for intersecting paths. But since "--stat --cc" shows the first-parent stat, and since we're computing that diff anyway, we enable DIFF_FORMAT_DIFFSTAT for the first parent. This outputs the stat information immediately, saving us from running a separate first-parent diff later. But where does that output go? Normally it goes directly to stdout, but because o->emitted_symbols is set, we queue it. As a result, we don't actually print the diffstat for the merge commit (yet), which is wrong. 3. Next we compute the diff for C. We're actually showing a patch again, so we end up in diff_flush_patch_all_file_pairs(), but this time we have the queued stat from step 2 waiting in our struct. We add new elements to it for C's diff, and then flush the whole thing. And we see the diffstat from M as part of C's diff, which is wrong. So triggering the bug really does require the combination of all of those options. To fix it, we can simply restore o->emitted_symbols to NULL after flushing it, so that it does not affect anything outside of diff_flush_patch_all_file_pairs(). This intuitively makes sense, since nobody outside of that function is going to bother flushing it, so we would not want them to write to it either. In fact, we could take this a step further and turn the local "esm" struct into a non-static variable that goes away after the function ends. However, since it contains a dynamically sized array, we benefit from amortizing the cost of allocations over many calls. So we'll leave it as static to retain that benefit. But let's push the zero-ing of esm.nr into the conditional for "if (o->emitted_symbols)" to make it clear that we do not expect esm to hold any values if we did not just try to use it. With the code as it is written now, if we did encounter such a case (which I think would be a bug), we'd silently leak those values without even bothering to display them. With this change, we'd at least eventually show them, and somebody would notice. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24t4006: resurrect commented-out testsLibravatar Jeff King1-23/+32
This set of tests was added by 4434e6ba6c (tests: check --[short]stat output after chmod, 2012-05-01), and is primarily about the handling of binary versus text files. Later, 74faaa16f0 (Fix "git diff --stat" for interesting - but empty - file changes, 2012-10-17) changed the stat output so that the empty text file is mentioned rather than omitted. That commit just comments out these tests. There's no discussion in the commit message, but the original email[1] says: NOTE! This does break two of our tests, so we clearly did this on purpose, or at least tested for it. I just uncommented the subtests that this makes irrelevant, and changed the output of another one. I don't think they're irrelevant, though. We should be testing this "mode change only" case and making sure that it has the post-74faaa16f0 behavior. So this commit brings back those tests, with the current expected output. [1] https://public-inbox.org/git/CA+55aFz88GPJcfMSqiyY+u0Cdm48bEyrsTGxHVJbGsYsDg=Q5w@mail.gmail.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-23checkout: fix regression in checkout -b on intitial checkoutLibravatar Ben Peart1-1/+1
When doing a 'checkout -b' do a full checkout including updating the working tree when doing the initial checkout. As the new test involves an filesystem access, do it later in the sequence to give chance to other cheaper tests to leave early. This fixes the regression in behavior caused by fa655d8411 (checkout: optimize "git checkout -b <new_branch>", 2018-08-16). Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-23checkout: add test demonstrating regression with checkout -b on initial commitLibravatar Ben Peart1-0/+9
Commit fa655d8411 (checkout: optimize "git checkout -b <new_branch>", 2018-08-16) introduced an unintentional change in behavior for 'checkout -b' after doing 'clone --no-checkout'. Add a test to demonstrate the changed behavior to be used in a later patch to verify the fix. Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22attr: do not mark queried macros as unsetLibravatar Jeff King1-0/+20
Since 60a12722ac (attr: remove maybe-real, maybe-macro from git_attr, 2017-01-27), we will always mark an attribute macro (e.g., "binary") that is specifically queried for as "unspecified", even though listing _all_ attributes would display it at set. E.g.: $ echo "* binary" >.gitattributes $ git check-attr -a file file: binary: set file: diff: unset file: merge: unset file: text: unset $ git check-attr binary file file: binary: unspecified The problem stems from an incorrect conversion of the optimization from 06a604e670 (attr: avoid heavy work when we know the specified attr is not defined, 2014-12-28). There we tried in collect_some_attrs() to avoid even looking at the attr_stack when the user has asked for "foo" and we know that "foo" did not ever appear in any .gitattributes file. It used a flag "maybe_real" in each attribute struct, where "real" meant that the attribute appeared in an actual file (we have to make this distinction because we also create an attribute struct for any names that are being queried). But as explained in that commit message, the meaning of "real" was tangled with some special cases around macros. When 60a12722ac later refactored the macro code, it dropped maybe_real entirely. This missed the fact that "maybe_real" could be unset for two reasons: because of a macro, or because it was never found during parsing. This had two results: - the optimization in collect_some_attrs() ceased doing anything meaningful, since it no longer kept track of "was it found during parsing" - worse, it actually kicked in when the caller _did_ ask about a macro by name, causing us to mark it as unspecified It should be possible to salvage this optimization, but let's start with just removing the remnants. It hasn't been doing anything (except creating bugs) since 60a12722ac, and nobody seems to have noticed the performance regression. It's more important to fix the correctness problem clearly first. I've added two tests here. The second one actually shows off the bug. The test of "check-attr -a" is not strictly necessary, but we currently do not test attribute macros much, and the builtin "binary" not at all. So this increases our general test coverage, as well as making sure we didn't mess up this related case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22tests: explicitly use `test-tool.exe` on WindowsLibravatar Johannes Schindelin1-1/+1
In 8abfdf44c882 (tests: explicitly use `git.exe` on Windows, 2018-11-14), we made sure to use the `.exe` file extension when using an absolute path to `git.exe`, to avoid getting confused with a file or directory in the same place that lacks said file extension. For the same reason, we need to handle test-tool.exe the same way. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22commit-graph: rename "large edges" to "extra edges"Libravatar SZEDER Gábor1-7/+7
The optional 'Large Edge List' chunk of the commit graph file stores parent information for commits with more than two parents, and the names of most of the macros, variables, struct fields, and functions related to this chunk contain the term "large edges", e.g. write_graph_chunk_large_edges(). However, it's not a really great term, as the edges to the second and subsequent parents stored in this chunk are not any larger than the edges to the first and second parents stored in the "main" 'Commit Data' chunk. It's the number of edges, IOW number of parents, that is larger compared to non-merge and "regular" two-parent merge commits. And indeed, two functions in 'commit-graph.c' have a local variable called 'num_extra_edges' that refer to the same thing, and this "extra edges" term is much better at describing these edges. So let's rename all these references to "large edges" in macro, variable, function, etc. names to "extra edges". There is a GRAPH_OCTOPUS_EDGES_NEEDED macro as well; for the sake of consistency rename it to GRAPH_EXTRA_EDGES_NEEDED. We can do so safely without causing any incompatibility issues, because the term "large edges" doesn't come up in the file format itself in any form (the chunk's magic is {'E', 'D', 'G', 'E'}, there is no 'L' in there), but only in the specification text. The string "large edges", however, does come up in the output of 'git commit-graph read' and in tests looking at its input, but that command is explicitly documented as debugging aid, so we can change its output and the affected tests safely. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'ot/ref-filter-object-info'Libravatar Junio C Hamano1-0/+6
The "--format=<placeholder>" option of for-each-ref, branch and tag learned to show a few more traits of objects that can be learned by the object_info API. * ot/ref-filter-object-info: ref-filter: give uintmax_t to format with %PRIuMAX ref-filter: add docs for new options ref-filter: add tests for deltabase ref-filter: add deltabase option ref-filter: add tests for objectsize:disk ref-filter: add check for negative file size ref-filter: add objectsize:disk option
2019-01-18Merge branch 'sg/stress-test'Libravatar Junio C Hamano9-133/+308
Flaky tests can now be repeatedly run under load with the "--stress" option. * sg/stress-test: test-lib: add the '--stress' option to run a test repeatedly under load test-lib-functions: introduce the 'test_set_port' helper function test-lib: set $TRASH_DIRECTORY earlier test-lib: consolidate naming of test-results paths test-lib: parse command line options earlier test-lib: parse options in a for loop to keep $@ intact test-lib: extract Bash version check for '-x' tracing test-lib: translate SIGTERM and SIGHUP to an exit
2019-01-18Merge branch 'tg/t5570-drop-racy-test'Libravatar Junio C Hamano2-24/+3
An inherently racy test that caused intermittent failures has been removed. * tg/t5570-drop-racy-test: Revert "t/lib-git-daemon: record daemon log" t5570: drop racy test
2019-01-18Merge branch 'so/cherry-pick-always-allow-m1'Libravatar Junio C Hamano3-11/+15
"git cherry-pick -m1" was forbidden when picking a non-merge commit, even though there _is_ parent number 1 for such a commit. This was done to avoid mistakes back when "cherry-pick" was about picking a single commit, but is no longer useful with "cherry-pick" that can pick a range of commits. Now the "-m$num" option is allowed when picking any commit, as long as $num names an existing parent of the commit. Technically this is a backward incompatible change; hopefully nobody is relying on the error-checking behaviour. * so/cherry-pick-always-allow-m1: t3506: validate '-m 1 -ff' is now accepted for non-merge commits t3502: validate '-m 1' argument is now accepted for non-merge commits cherry-pick: do not error on non-merge commits when '-m 1' is specified t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
2019-01-18Merge branch 'nd/worktree-remove-with-uninitialized-submodules'Libravatar Junio C Hamano1-0/+37
"git worktree remove" and "git worktree move" refused to work when there is a submodule involved. This has been loosened to ignore uninitialized submodules. * nd/worktree-remove-with-uninitialized-submodules: worktree: allow to (re)move worktrees with uninitialized submodules
2019-01-18Merge branch 'sg/test-bash-version-fix'Libravatar Junio C Hamano1-2/+2
The test suite tried to see if it is run under bash, but the check itself failed under some other implementations of shell (notably under NetBSD). This has been corrected. * sg/test-bash-version-fix: test-lib: check Bash version for '-x' without using shell arrays
2019-01-18Merge branch 'cy/zsh-completion-SP-in-path'Libravatar Junio C Hamano1-5/+5
With zsh, "git cmd path<TAB>" was completed to "git cmd path name" when the completed path has a special character like SP in it, without any attempt to keep "path name" a single filename. This has been fixed to complete it to "git cmd path\ name" just like Bash completion does. * cy/zsh-completion-SP-in-path: completion: treat results of git ls-tree as file paths zsh: complete unquoted paths with spaces correctly
2019-01-18Merge branch 'sb/submodule-unset-core-worktree-when-worktree-is-lost'Libravatar Junio C Hamano3-3/+14
The core.worktree setting in a submodule repository should not be pointing at a directory when the submodule loses its working tree (e.g. getting deinit'ed), but the code did not properly maintain this invariant. * sb/submodule-unset-core-worktree-when-worktree-is-lost: submodule deinit: unset core.worktree submodule--helper: fix BUG message in ensure_core_worktree submodule: unset core.worktree if no working tree is present submodule update: add regression test with old style setups