summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-06-27progress: use term_clear_line()Libravatar SZEDER Gábor1-3/+3
To make sure that the previously displayed progress line is completely covered up when the new line is shorter, commit 545dc345eb (progress: break too long progress bar lines, 2019-04-12) added a bunch of calculations to figure out how many characters it needs to overwrite with spaces. Use the just introduced term_clear_line() helper function to, well, clear the last line, making all these calculations unnecessary, and thus simplifying the code considerably. Three tests in 't5541-http-push-smart.sh' 'grep' for specific text shown in the progress lines at the beginning of the line, but now those lines begin either with the ANSI escape sequence or with the terminal width worth of space characters clearing the line. Relax the 'grep' patterns to match anywhere on the line. Note that only two of these three tests fail without relaxing their 'grep' pattern, but the third looks for the absence of the pattern, so it still succeeds, but without the adjustment would potentially hide future regressions. Note also that with this change we no longer need the length of the previously displayed progress line, so the strbuf added to 'struct progress' in d53ba841d4 (progress: assemble percentage and counters in a strbuf before printing, 2019-04-05) is not strictly necessary anymore. We still keep it, though, as it avoids allocating and releasing a strbuf each time the progress is updated. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27rebase: fix garbled progress display with '-x'Libravatar SZEDER Gábor1-2/+2
When running a command with the 'exec' instruction during an interactive rebase session, or for a range of commits using 'git rebase -x', the output can be a bit garbled when the name of the command is short enough: $ git rebase -x true HEAD~5 Executing: true Executing: true Executing: true Executing: true Executing: true) Successfully rebased and updated refs/heads/master. Note the ')' at the end of the last line. It gets more garbled as the range of commits increases: $ git rebase -x true HEAD~50 Executing: true) [ repeated 3 more times ] Executing: true0) [ repeated 44 more times ] Executing: true00) Successfully rebased and updated refs/heads/master. Those extra numbers and ')' are remnants of the previously displayed "Rebasing (N/M)" progress lines that are usually completely overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and the "N/M" part is long. Make sure that the previously displayed "Rebasing (N/M)" line is cleared by using the term_clear_line() helper function added in the previous patch. Do so only when not being '--verbose', because in that case these "Rebasing (N/M)" lines are not printed as progress (i.e. as lines with '\r' at the end), but as "regular" output (with '\n' at the end). A couple of other rebase commands print similar messages, e.g. "Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break' commands, or the "Successfully rebased and updated <full-ref>." at the very end. These are so long that they practically always overwrite that "Rebasing (N/M)" progress line, but let's be prudent, and clear the last line before printing these, too. In 't3420-rebase-autostash.sh' two helper functions prepare the expected output of four tests that check the full output of 'git rebase' and thus are affected by this change, so adjust their expectations to account for the new line clearing. Note that this patch doesn't completely eliminate the possibility of similar garbled outputs, e.g. some error messages from rebase or the "Auto-merging <file>" message from within the depths of the merge machinery might not be long enough to completely cover the last "Rebasing (N/M)" line. This patch doesn't do anything about them, because dealing with them individually would result in way too much churn, while having a catch-all term_clear_line() call in the common code path of pick_commits() would hide the "Rebasing (N/M)" line way too soon, and it would either flicker or be invisible. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24t3404: make the 'rebase.missingCommitsCheck=ignore' test more focusedLibravatar SZEDER Gábor1-14/+1
The test 'rebase -i respects rebase.missingCommitsCheck = warn' is mainly interested in the warning about the dropped commits, but it checks the whole output of 'git rebase', including progress lines and what not that are not at all relevant to 'rebase.missingCommitsCheck', but make it necessary to update this test whenever e.g. the way we show progress is updated (as it will happen in one of the later patches of this series). Modify the test to verify only the first four lines of 'git rebase's output that contain all the important lines, notably the line containing the "Warning:" itself and the oneline log of the dropped commit. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24t3404: modernize here doc styleLibravatar SZEDER Gábor1-65/+58
In 't3404-rebase-interactive.sh' the expected output of several tests is prepared from here documents, which are outside of 'test_expect_success' blocks and have spaces around redirection operators. Move these here documents into the corresponding 'test_expect_success' block and avoid spaces between filename and redition operators. Furthermore, quote the here docs' delimiter word to prevent parameter expansions and what not, where applicable. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-06Merge branch 'en/merge-directory-renames-fix'Libravatar Junio C Hamano1-0/+116
Recent code restructuring of merge-recursive engine introduced a regression dealing with rename/add conflict. * en/merge-directory-renames-fix: merge-recursive: restore accidentally dropped setting of path
2019-06-05merge-recursive: restore accidentally dropped setting of pathLibravatar Elijah Newren1-0/+116
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs to a diff_filespec", 2019-04-05), we actually switched from (oid,mode,path) triplets to a diff_filespec -- but most callsites in the patch only needed to worry about oid and mode so the commit message focused on that. The oversight in the commit message apparently spilled over to the code as well; one of the dozen or so callsites accidentally dropped the setting of the path in the conversion. Restore the path setting in that location. Also, this pointed out that our testsuite was lacking a good rename/add test, at least one that involved the need for merge content with the rename. Add such a test, and since rename/add vs. add/rename could possibly be important, redo the merge the opposite direction to make sure we don't have issues with the direction of the merge. These testcases failed before restoring the setting of path, but with the paths appropriately set the testcases both pass. Reported-by: Ben Humphreys <behumphreys@atlassian.com> Based-on-patch-by: SZEDER Gábor <szeder.dev@gmail.com> Tested-by: Ben Humphreys <behumphreys@atlassian.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-03Merge branch 'cc/list-objects-filter-wo-sparse-path'Libravatar Junio C Hamano2-84/+26
Disable "--filter=sparse:path=<path>" that would allow reading from paths on the filesystem. * cc/list-objects-filter-wo-sparse-path: list-objects-filter: disable 'sparse:path' filters
2019-05-30Merge branch 'js/rebase-deprecate-preserve-merges'Libravatar Junio C Hamano2-7/+13
A bit more leftover clean-up to deprepcate "rebase -p". * js/rebase-deprecate-preserve-merges: rebase docs: recommend `-r` over `-p` docs: say that `--rebase=preserve` is deprecated tests: mark a couple more test cases as requiring `rebase -p`
2019-05-30Merge branch 'sg/trace2-rename'Libravatar Junio C Hamano5-32/+32
Rename environment variables that are used to control the "trace2" mechanism to a more readable name. * sg/trace2-rename: trace2: document the supported values of GIT_TRACE2* env variables trace2: rename environment variables to GIT_TRACE2*
2019-05-30Merge branch 'nd/diff-parseopt'Libravatar Junio C Hamano4-0/+94
A brown-paper-bag bugfix to a change already in 'master'. * nd/diff-parseopt: parse-options: check empty value in OPT_INTEGER and OPT_ABBREV diff-parseopt: restore -U (no argument) behavior diff-parseopt: correct variable types that are used by parseopt
2019-05-29list-objects-filter: disable 'sparse:path' filtersLibravatar Christian Couder2-84/+26
If someone wants to use as a filter a sparse file that is in the repository, something like "--filter=sparse:oid=<ref>:<path>" already works. So 'sparse:path' is only interesting if the sparse file is not in the repository. In this case though the current implementation has a big security issue, as it makes it possible to ask the server to read any file, like for example /etc/password, and to explore the filesystem, as well as individual lines of files. If someone is interested in using a sparse file that is not in the repository as a filter, then at the minimum a config option, such as "uploadpack.sparsePathFilter", should be implemented first to restrict the directory from which the files specified by 'sparse:path' can be read. For now though, let's just disable 'sparse:path' filters. Helped-by: Matthew DeVore <matvore@google.com> Helped-by: Jeff Hostetler <git@jeffhostetler.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29diff-parseopt: restore -U (no argument) behaviorLibravatar Nguyễn Thái Ngọc Duy4-0/+94
Before d473e2e0e8 (diff.c: convert -U|--unified, 2019-01-27), -U and --unified are implemented with a custom parser opt_arg() in diff.c. I didn't check this code carefully and not realize that it's the equivalent of PARSE_OPT_NONEG | PARSE_OPT_OPTARG. In other words, if -U is specified without any argument, the option should be accepted, and the default value should be used. Without PARSE_OPT_OPTARG, parse_options() will reject this case and cause a regression. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28tests: mark a couple more test cases as requiring `rebase -p`Libravatar Johannes Schindelin2-7/+13
The `--preserve-merges` option has been deprecated, and as a consequence we started to mark test cases that require that option to be supported, in preparation for removing that support eventually. Since we marked those test cases, a couple more crept into the test suite, and with this patch, we mark them, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: rename environment variables to GIT_TRACE2*Libravatar SZEDER Gábor5-32/+32
For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly. Most of the established GIT_* environment variables don't use abbreviations, and in case of the few that do (GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the abbreviations (DIR and OPTS) stand for. But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or ...?! The trace2 facility, as the '2' suffix in its name suggests, is supposed to eventually supercede Git's original trace facility. It's reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2; there is no such thing is 'GIT_TR'. All trace2-specific config variables are, very sensibly, in the 'trace2' section, not in 'tr2'. OTOH, we don't gain anything at all by omitting the last three characters of "trace" from the names of these environment variables. So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, before they make their way into a stable release. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'jk/get-oid-indexed-object-name'Libravatar Junio C Hamano1-6/+2
The codepath to parse :<path> that obtains the object name for an indexed object has been made more robust. * jk/get-oid-indexed-object-name: get_oid: handle NULL repo->index
2019-05-19Merge branch 'tz/test-lib-check-working-jgit'Libravatar Junio C Hamano1-1/+1
A prerequiste check in the test suite to see if a working jgit is available was made more robust. * tz/test-lib-check-working-jgit: test-lib: try harder to ensure a working jgit
2019-05-19Merge branch 'es/check-non-portable-pre-5.10'Libravatar Junio C Hamano1-4/+5
Developer support update. * es/check-non-portable-pre-5.10: check-non-portable-shell: support Perl versions older than 5.10
2019-05-19Merge branch 'js/fsmonitor-refresh-after-discarding-index'Libravatar Junio C Hamano2-1/+31
The fsmonitor interface got out of sync after the in-core index file gets discarded, which has been corrected. * js/fsmonitor-refresh-after-discarding-index: fsmonitor: force a refresh after the index was discarded fsmonitor: demonstrate that it is not refreshed after discard_index()
2019-05-19Merge branch 'js/t5580-unc-alternate-test'Libravatar Junio C Hamano1-0/+12
An additional test for MinGW * js/t5580-unc-alternate-test: t5580: verify that alternates can be UNC paths
2019-05-19Merge branch 'bl/t4253-exit-code-from-format-patch'Libravatar Junio C Hamano1-2/+4
Avoid patterns to pipe output from a git command to feed another command in tests. * bl/t4253-exit-code-from-format-patch: t4253-am-keep-cr-dos: avoid using pipes
2019-05-19Merge branch 'dl/difftool-mergetool'Libravatar Junio C Hamano2-61/+126
Update "git difftool" and "git mergetool" so that the combinations of {diff,merge}.{tool,guitool} configuration variables serve as fallback settings of each other in a sensible order. * dl/difftool-mergetool: difftool: fallback on merge.guitool difftool: make --gui, --tool and --extcmd mutually exclusive mergetool: fallback to tool when guitool unavailable mergetool--lib: create gui_mode function mergetool: use get_merge_tool function t7610: add mergetool --gui tests t7610: unsuppress output
2019-05-19Merge branch 'js/t6500-use-windows-pid-on-mingw'Libravatar Junio C Hamano1-1/+9
Future-proof a test against an update to MSYS2 runtime v3.x series. * js/t6500-use-windows-pid-on-mingw: t6500(mingw): use the Windows PID of the shell
2019-05-19Merge branch 'jk/apache-lsan'Libravatar Junio C Hamano1-0/+1
Allow tests that involve httpd to be run under leak sanitizer, just like we can already do so under address sanitizer. * jk/apache-lsan: t/lib-httpd: pass LSAN_OPTIONS through apache
2019-05-19Merge branch 'nd/parse-options-aliases'Libravatar Junio C Hamano2-0/+20
Attempt to use an abbreviated option in "git clone --recurs" is responded by a request to disambiguate between --recursive and --recurse-submodules, which is bad because these two are synonyms. The parse-options API has been extended to define such synonyms more easily and not produce an unnecessary failure. * nd/parse-options-aliases: parse-options: don't emit "ambiguous option" for aliases
2019-05-19Merge branch 'dl/branch-from-3dot-merge-base'Libravatar Junio C Hamano2-30/+40
"git branch new A...B" and "git checkout -b new A...B" have been taught that in their contexts, the notation A...B means "the merge base between these two commits", just like "git checkout A...B" detaches HEAD at that commit. * dl/branch-from-3dot-merge-base: branch: make create_branch accept a merge base rev t2018: cleanup in current test
2019-05-19Merge branch 'ab/perf-installed-fix'Libravatar Junio C Hamano4-27/+53
Performance test framework has been broken and measured the version of Git that happens to be on $PATH, not the specified one to measure, for a while, which has been corrected. * ab/perf-installed-fix: perf-lib.sh: forbid the use of GIT_TEST_INSTALLED perf tests: add "bindir" prefix to git tree test results perf-lib.sh: remove GIT_TEST_INSTALLED from perf-lib.sh perf-lib.sh: make "./run <revisions>" use the correct gits perf aggregate: remove GIT_TEST_INSTALLED from --codespeed perf README: correct docs for 3c8f12c96c regression
2019-05-19Merge branch 'dl/warn-tagging-a-tag'Libravatar Junio C Hamano1-1/+1
Typofix. * dl/warn-tagging-a-tag: tag: fix typo in nested tagging hint
2019-05-15test-lib: try harder to ensure a working jgitLibravatar Todd Zullinger1-1/+1
The JGIT prereq uses `type jgit` to determine whether jgit is present. While this is usually sufficient, it won't help if the jgit found is badly broken. This wastes time running tests which fail due to no fault of our own. Use `jgit --version` instead, to guard against cases where jgit is present on the system, but will fail to run, e.g. because of some JRE issue, or missing Java dependencies. Checking that it gets far enough to process the '--version' argument isn't perfect, but seems to be good enough in practice. It's also consistent with how we detect some other dependencies, see e.g. the CURL and UNZIP prerequisites. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15get_oid: handle NULL repo->indexLibravatar Jeff King1-6/+2
When get_oid() and its helpers see an index name like ":.gitmodules", they try to load the index on demand, like: if (repo->index->cache) repo_read_index(repo); However, that misses the case when "repo->index" itself is NULL; we'll segfault in the conditional. This never happens with the_repository; there we always point its index field to &the_index. But a submodule repository may have a NULL index field until somebody calls repo_read_index(). This bug is triggered by t7411, but it was hard to notice because it's in an expect_failure block. That test was added by 2b1257e463 (t/helper: add test-submodule-nested-repo-config, 2018-10-25). Back then we had no easy way to access the .gitmodules blob of a submodule repo, so we expected (and got) an error message to that effect. Later, d9b8b8f896 (submodule-config.c: use repo_get_oid for reading .gitmodules, 2019-04-16) started looking in the correct repo, which is when we started triggering the segfault. With this fix, the test starts passing (once we clean it up as its comment instructs). Note that as far as I know, this bug could not be triggered outside of the test suite. It requires resolving an index name in a submodule, and all of the code paths (aside from test-tool) which do that either load the index themselves, or always pass the_repository. Ultimately it comes from 3a7a698e93 (sha1-name.c: remove implicit dependency on the_index, 2019-01-12), which replaced a check of "the_index.cache" with "repo->index->cache". So even if there is another way to trigger it, it wouldn't affect any versions before then. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13Merge branch 'pw/clean-sequencer-state-upon-final-commit'Libravatar Junio C Hamano2-0/+75
"git chery-pick" (and "revert" that shares the same runtime engine) that deals with multiple commits got confused when the final step gets stopped with a conflict and the user concluded the sequence with "git commit". Attempt to fix it by cleaning up the state files used by these commands in such a situation. * pw/clean-sequencer-state-upon-final-commit: fix cherry-pick/revert status after commit commit/reset: try to clean up sequencer state
2019-05-13Merge branch 'jk/perf-aggregate-wo-libjson'Libravatar Junio C Hamano1-2/+2
The script to aggregate perf result unconditionally depended on libjson-perl even though it did not have to, which has been corrected. * jk/perf-aggregate-wo-libjson: t/perf: depend on perl JSON only when using --codespeed
2019-05-13Merge branch 'jk/p5302-avoid-collision-check-cost'Libravatar Junio C Hamano1-13/+18
Fix index-pack perf test so that the repeated invocations always run in an empty repository, which emulates the initial clone situation better. * jk/p5302-avoid-collision-check-cost: p5302: create the repo in each index-pack test
2019-05-13Merge branch 'ew/repack-with-bitmaps-by-default'Libravatar Junio C Hamano4-7/+21
The connectivity bitmaps are created by default in bare repositories now; also the pathname hash-cache is created by default to avoid making crappy deltas when repacking. * ew/repack-with-bitmaps-by-default: pack-objects: default to writing bitmap hash-cache t5310: correctly remove bitmaps for jgit test repack: enable bitmaps by default on bare repos
2019-05-13Merge branch 'js/partial-clone-connectivity-check'Libravatar Junio C Hamano1-0/+26
During an initial "git clone --depth=..." partial clone, it is pointless to spend cycles for a large portion of the connectivity check that enumerates and skips promisor objects (which by definition is all objects fetched from the other side). This has been optimized out. * js/partial-clone-connectivity-check: t/perf: add perf script for partial clones clone: do faster object check for partial clones
2019-05-13Merge branch 'jh/trace2-sid-fix'Libravatar Junio C Hamano3-21/+113
Polishing of the new trace2 facility continues. The system-level configuration can specify site-wide trace2 settings, which can be overridden with per-user configuration and environment variables. * jh/trace2-sid-fix: trace2: fixup access problem on /etc/gitconfig in read_very_early_config trace2: update docs to describe system/global config settings trace2: make SIDs more unique trace2: clarify UTC datetime formatting trace2: report peak memory usage of the process trace2: use system/global config for default trace2 settings config: add read_very_early_config() trace2: find exec-dir before trace2 initialization trace2: add absolute elapsed time to start event trace2: refactor setting process starting time config: initialize opts structure in repo_read_config()
2019-05-13difftool: fallback on merge.guitoolLibravatar Denton Liu1-0/+16
In git-difftool.txt, it says 'git difftool' falls back to 'git mergetool' config variables when the difftool equivalents have not been defined. However, when `diff.guitool` is missing, it doesn't fallback to anything. Make git-difftool fallback to `merge.guitool` when `diff.guitool` is missing. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13difftool: make --gui, --tool and --extcmd mutually exclusiveLibravatar Denton Liu1-0/+8
In git-difftool, these options specify which tool to ultimately run. As a result, they are logically conflicting. Explicitly disallow these options from being used together. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13mergetool: fallback to tool when guitool unavailableLibravatar Denton Liu1-0/+19
In git-difftool, if the tool is called with --gui but `diff.guitool` is not set, it falls back to `diff.tool`. Make git-mergetool also fallback from `merge.guitool` to `merge.tool` if the former is undefined. If git-difftool, when called with `--gui`, were to use `get_configured_mergetool` in a future patch, it would also get the fallback behavior in the following precedence: 1. diff.guitool 2. merge.guitool 3. diff.tool 4. merge.tool The behavior for when difftool or mergetool are called without `--gui` should be identical with or without this patch. Note that the search loop could be written as sections="merge" keys="tool" if diff_mode then sections="diff $sections" fi if gui_mode then keys="guitool $keys" fi merge_tool=$( IFS=' ' for key in $keys do for section in $sections do selected=$(git config $section.$key) if test -n "$selected" then echo "$selected" return fi done done) which would make adding a mode in the future much easier. However, adding a new mode will likely never happen as it is highly discouraged so, as a result, it is written in its current form so that it is more readable for future readers. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13check-non-portable-shell: support Perl versions older than 5.10Libravatar Eric Sunshine1-4/+5
For thoroughness when checking for one-shot environment variable assignments at shell function call sites, check-non-portable-shell stitches together incomplete lines (those ending with backslash). This allows it to correctly flag such undesirable usage even when the variable assignment and function call are split across lines, for example: FOO=bar \ func where 'func' is a shell function. The stitching is accomplished like this: while (<>) { chomp; # stitch together incomplete lines (those ending with "\") while (s/\\$//) { $_ .= readline; chomp; } # detect unportable/undesirable shell constructs ... } Although this implementation is well supported in reasonably modern Perl versions (5.10 and later), it fails with older versions (such as Perl 5.8 shipped with ancient Mac OS 10.5). In particular, in older Perl versions, 'readline' is not connected to the file handle associated with the "magic" while (<>) {...} construct, so 'readline' throws a "readline() on unopened filehandle" error. Work around this problem by dropping readline() and instead incorporating the stitching of incomplete lines directly into the existing while (<>) {...} loop. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09tag: fix typo in nested tagging hintLibravatar Denton Liu1-1/+1
In eea9c1e78f (tag: advise on nested tags, 2019-04-04), tag was taught to hint at the user if a nested tag is made. However, this message had a typo and it said "The object referred to by your new is...", which was missing a "tag" after "new". Fix this message by adding the "tag". Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09Merge branch 'jt/submodule-repo-is-with-worktree'Libravatar Junio C Hamano1-0/+24
The logic to tell if a Git repository has a working tree protects "git branch -D" from removing the branch that is currently checked out by mistake. The implementation of this logic was broken for repositories with unusual name, which unfortunately is the norm for submodules these days. This has been fixed. * jt/submodule-repo-is-with-worktree: worktree: update is_bare heuristics
2019-05-09Merge branch 'jk/prune-optim'Libravatar Junio C Hamano1-0/+8
A follow-up test for an earlier "git prune" improvements. * jk/prune-optim: t5304: add a test for pruning with bitmaps
2019-05-09Merge branch 'js/misc-doc-fixes'Libravatar Junio C Hamano8-24/+230
"make check-docs", "git help -a", etc. did not account for cases where a particular build may deliberately omit some subcommands, which has been corrected. * js/misc-doc-fixes: Turn `git serve` into a test helper test-tool: handle the `-C <directory>` option just like `git` check-docs: do not bother checking for legacy scripts' documentation docs: exclude documentation for commands that have been excluded check-docs: allow command-list.txt to contain excluded commands help -a: do not list commands that are excluded from the build Makefile: drop the NO_INSTALL variable remote-testgit: move it into the support directory for t5801
2019-05-09Merge branch 'dr/ref-filter-push-track-fix'Libravatar Junio C Hamano1-2/+11
%(push:track) token used in the --format option to "git for-each-ref" and friends was not showing the right branch, which has been fixed. * dr/ref-filter-push-track-fix: ref-filter: use correct branch for %(push:track)
2019-05-09Merge branch 'jt/clone-server-option'Libravatar Junio C Hamano1-0/+41
"git clone" learned a new --server-option option when talking over the protocol version 2. * jt/clone-server-option: clone: send server options when using protocol v2 transport: die if server options are unsupported
2019-05-09Merge branch 'tb/unexpected'Libravatar Junio C Hamano5-12/+133
Code tightening against a "wrong" object appearing where an object of a different type is expected, instead of blindly assuming that the connection between objects are correctly made. * tb/unexpected: rev-list: detect broken root trees rev-list: let traversal die when --missing is not in use get_commit_tree(): return NULL for broken tree list-objects.c: handle unexpected non-tree entries list-objects.c: handle unexpected non-blob entries t: introduce tests for unexpected object types t: move 'hex2oct' into test-lib-functions.sh
2019-05-09Merge branch 'nd/sha1-name-c-wo-the-repository'Libravatar Junio C Hamano1-5/+1
Further code clean-up to allow the lowest level of name-to-object mapping layer to work with a passed-in repository other than the default one. * nd/sha1-name-c-wo-the-repository: (34 commits) sha1-name.c: remove the_repo from get_oid_mb() sha1-name.c: remove the_repo from other get_oid_* sha1-name.c: remove the_repo from maybe_die_on_misspelt_object_name submodule-config.c: use repo_get_oid for reading .gitmodules sha1-name.c: add repo_get_oid() sha1-name.c: remove the_repo from get_oid_with_context_1() sha1-name.c: remove the_repo from resolve_relative_path() sha1-name.c: remove the_repo from diagnose_invalid_index_path() sha1-name.c: remove the_repo from handle_one_ref() sha1-name.c: remove the_repo from get_oid_1() sha1-name.c: remove the_repo from get_oid_basic() sha1-name.c: remove the_repo from get_describe_name() sha1-name.c: remove the_repo from get_oid_oneline() sha1-name.c: add repo_interpret_branch_name() sha1-name.c: remove the_repo from interpret_branch_mark() sha1-name.c: remove the_repo from interpret_nth_prior_checkout() sha1-name.c: remove the_repo from get_short_oid() sha1-name.c: add repo_for_each_abbrev() sha1-name.c: store and use repo in struct disambiguate_state sha1-name.c: add repo_find_unique_abbrev_r() ...
2019-05-09Merge branch 'cc/replace-graft-peel-tags'Libravatar Junio C Hamano1-3/+28
When given a tag that points at a commit-ish, "git replace --graft" failed to peel the tag before writing a replace ref, which did not make sense because the old graft mechanism the feature wants to mimick only allowed to replace one commit object with another. This has been fixed. * cc/replace-graft-peel-tags: replace: peel tag when passing a tag first to --graft replace: peel tag when passing a tag as parent to --graft t6050: redirect expected error output to a file t6050: use test_line_count instead of wc -l
2019-05-09Merge branch 'js/trace2-to-directory'Libravatar Junio C Hamano1-0/+15
The trace2 tracing facility learned to auto-generate a filename when told to log to a directory. * js/trace2-to-directory: trace2: write to directory targets
2019-05-09Merge branch 'dl/merge-cleanup-scissors-fix'Libravatar Junio C Hamano5-80/+297
The list of conflicted paths shown in the editor while concluding a conflicted merge was shown above the scissors line when the clean-up mode is set to "scissors", even though it was commented out just like the list of updated paths and other information to help the user explain the merge better. * dl/merge-cleanup-scissors-fix: cherry-pick/revert: add scissors line on merge conflict sequencer.c: save and restore cleanup mode merge: add scissors line on merge conflict merge: cleanup messages like commit parse-options.h: extract common --cleanup option commit: extract cleanup_mode functions to sequencer t7502: clean up style t7604: clean up style t3507: clean up style t7600: clean up style