summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-10-06tests: let --immediate and --write-junit-xml play well togetherLibravatar Johannes Schindelin1-16/+22
When the `--immediate` option is in effect, any test failure will immediately exit the test script. Together with `--write-junit-xml`, we will want the JUnit-style `.xml` file to be finalized (and not leave the XML incomplete). Let's make it so. This comes in particularly handy when trying to debug via Azure Pipelines, where the JUnit-style XML is consumed to present the test results in an informative and helpful way. While at it, also handle the `error()` code path. The only remaining code path that sets `GIT_EXIT_OK` happens whenever the trash directory could not be set up, i.e. long before the JUnit XML was written, therefore we should _not_ try to finalize that XML in that case. It is tempting to change the `immediate` code path to just hand off to `error`, simplifying the code in the process. That would, however, result in a change of behavior (an additional error message) in the test suite, which is outside of the purview of the current patch series: its goal is to allow building Git with Visual Studio and testing it with a portable version of Git for Windows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06test-tool run-command: learn to run (parts of) the testsuiteLibravatar Johannes Schindelin1-0/+153
Git for Windows jumps through hoops to provide a development environment that allows to build Git and to run its test suite. To that end, an entire MSYS2 system, including GNU make and GCC is offered as "the Git for Windows SDK". It does come at a price: an initial download of said SDK weighs in with several hundreds of megabytes, and the unpacked SDK occupies ~2GB of disk space. A much more native development environment on Windows is Visual Studio. To help contributors use that environment, we already have a Makefile target `vcxproj` that generates a commit with project files (and other generated files), and Git for Windows' `vs/master` branch is continuously re-generated using that target. The idea is to allow building Git in Visual Studio, and to run individual tests using a Portable Git. The one missing thing is a way to run the entire test suite: neither `make` nor `prove` are required to run Git, therefore Git for Windows does not support those commands in the Portable Git. To help with that, add a simple test helper that exercises the `run_processes_parallel()` function to allow for running test scripts in parallel (which is really necessary, especially on Windows, as Git's test suite takes such a long time to run). This will also come in handy for the upcoming change to our Azure Pipeline: we will use this helper in a Portable Git to test the Visual Studio build of Git. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11Merge branch 'js/rebase-reschedule-applies-only-to-interactive'Libravatar Junio C Hamano1-0/+8
The configuration variable rebase.rescheduleFailedExec should be effective only while running an interactive rebase and should not affect anything when running an non-interactive one, which was not the case. This has been corrected. * js/rebase-reschedule-applies-only-to-interactive: rebase --am: ignore rebase.rescheduleFailedExec
2019-07-11Merge branch 'jt/t5551-test-chunked'Libravatar Junio C Hamano1-3/+2
Update smart-http test. * jt/t5551-test-chunked: t5551: test usage of chunked encoding explicitly
2019-07-09Merge branch 'ds/fetch-disable-force-notice'Libravatar Junio C Hamano1-0/+23
"git fetch" and "git pull" reports when a fetch results in non-fast-forward updates to let the user notice unusual situation. The commands learned "--no-shown-forced-updates" option to disable this safety feature. * ds/fetch-disable-force-notice: pull: add --[no-]show-forced-updates passthrough fetch: warn about forced updates in branch listing fetch: add --[no-]show-forced-updates argument
2019-07-09Merge branch 'jh/status-aheadbehind'Libravatar Junio C Hamano2-0/+39
"git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind. * jh/status-aheadbehind: status: ignore status.aheadbehind in porcelain formats status: warn when a/b calculation takes too long status: add status.aheadbehind setting
2019-07-09Merge branch 'sg/t5551-fetch-smart-error-is-translated'Libravatar Junio C Hamano1-2/+2
Test update. * sg/t5551-fetch-smart-error-is-translated: t5551: use 'test_i18ngrep' to check translated output
2019-07-09Merge branch 'ms/submodule-foreach-fix'Libravatar Junio C Hamano1-0/+7
"git submodule foreach" did not protect command line options passed to the command to be run in each submodule correctly, when the "--recursive" option was in use. * ms/submodule-foreach-fix: submodule foreach: fix recursion of options
2019-07-09Merge branch 'jh/msvc'Libravatar Junio C Hamano1-2/+2
Support to build with MSVC has been updated. * jh/msvc: msvc: ignore .dll and incremental compile output msvc: avoid debug assertion windows in Debug Mode msvc: do not pretend to support all signals msvc: add pragmas for common warnings msvc: add a compile-time flag to allow detailed heap debugging msvc: support building Git using MS Visual C++ msvc: update Makefile to allow for spaces in the compiler path msvc: fix detect_msys_tty() msvc: define ftello() msvc: do not re-declare the timespec struct msvc: mark a variable as non-const msvc: define O_ACCMODE msvc: include sigset_t definition msvc: fix dependencies of compat/msvc.c mingw: replace mingw_startup() hack obstack: fix compiler warning cache-tree/blame: avoid reusing the DEBUG constant t0001 (mingw): do not expect a specific order of stdout/stderr Mark .bat files as requiring CR/LF endings mingw: fix a typo in the msysGit-specific section
2019-07-09Merge branch 'sg/rebase-progress'Libravatar Junio C Hamano3-75/+55
Use "Erase in Line" CSI sequence that is already used in the editor support to clear cruft in the progress output. * sg/rebase-progress: progress: use term_clear_line() rebase: fix garbled progress display with '-x' pager: add a helper function to clear the last line in the terminal t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused t3404: modernize here doc style
2019-07-09Merge branch 'js/t0001-case-insensitive'Libravatar Junio C Hamano2-14/+23
Test update. * js/t0001-case-insensitive: t0001: fix on case-insensitive filesystems
2019-07-09Merge branch 'ab/fail-prereqs-in-test'Libravatar Junio C Hamano2-2/+2
Test updates. * ab/fail-prereqs-in-test: tests: mark two failing tests under FAIL_PREREQS
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano9-73/+387
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-07-09Merge branch 'jk/oidhash'Libravatar Junio C Hamano1-3/+3
Code clean-up to remove hardcoded SHA-1 hash from many places. * jk/oidhash: hashmap: convert sha1hash() to oidhash() hash.h: move object_id definition from cache.h khash: rename oid helper functions khash: drop sha1-specific map types pack-bitmap: convert khash_sha1 maps into kh_oid_map delta-islands: convert island_marks khash to use oids khash: rename kh_oid_t to kh_oid_set khash: drop broken oid_map typedef object: convert create_object() to use object_id object: convert internal hash_obj() to object_id object: convert lookup_object() to use object_id object: convert lookup_unknown_object() to use object_id pack-objects: convert locate_object_entry_hash() to object_id pack-objects: convert packlist_find() to use object_id pack-bitmap-write: convert some helpers to use object_id upload-pack: rename a "sha1" variable to "oid" describe: fix accidental oid/hash type-punning
2019-07-09Merge branch 'nd/fetch-multi-gc-once'Libravatar Junio C Hamano1-2/+5
"git fetch" that grabs from a group of remotes learned to run the auto-gc only once at the very end. * nd/fetch-multi-gc-once: fetch: only run 'gc' once when fetching multiple remotes
2019-07-09Merge branch 'es/rev-list-no-object-names'Libravatar Junio C Hamano1-0/+20
"git rev-list --objects" learned with "--no-object-names" option to squelch the path to the object that is used as a grouping hint for pack-objects. * es/rev-list-no-object-names: rev-list: teach --no-object-names to enable piping
2019-07-09Merge branch 'dl/includeif-onbranch'Libravatar Junio C Hamano1-0/+39
The conditional inclusion mechanism learned to base the choice on the branch the HEAD currently is on. * dl/includeif-onbranch: config: learn the "onbranch:" includeIf condition
2019-07-09Merge branch 'pw/rebase-abort-clean-rewritten'Libravatar Junio C Hamano1-1/+17
"git rebase --abort" used to leave refs/rewritten/ when concluding "git rebase -r", which has been corrected. * pw/rebase-abort-clean-rewritten: rebase --abort/--quit: cleanup refs/rewritten sequencer: return errors from sequencer_remove_state() rebase: warn if state directory cannot be removed rebase: fix a memory leak
2019-07-09Merge branch 'am/p4-branches-excludes'Libravatar Junio C Hamano2-5/+178
"git p4" update. * am/p4-branches-excludes: git-p4: respect excluded paths when detecting branches git-p4: add failing test for "git-p4: respect excluded paths when detecting branches" git-p4: don't exclude other files with same prefix git-p4: add failing test for "don't exclude other files with same prefix" git-p4: don't groom exclude path list on every commit git-p4: match branches case insensitively if configured git-p4: add failing test for "git-p4: match branches case insensitively if configured" git-p4: detect/prevent infinite loop in gitCommitByP4Change()
2019-07-09Merge branch 'tg/stash-ref-by-index-fix'Libravatar Junio C Hamano1-0/+18
"git stash show 23" used to work, but no more after getting rewritten in C; this regression has been corrected. * tg/stash-ref-by-index-fix: stash: fix show referencing stash index
2019-07-09Merge branch 'jk/trailers-use-config'Libravatar Junio C Hamano1-27/+44
"git interpret-trailers" always treated '#' as the comment character, regardless of core.commentChar setting, which has been corrected. * jk/trailers-use-config: interpret-trailers: load default config
2019-07-09Merge branch 'js/t3404-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * js/t3404-typofix: t3404: fix a typo
2019-07-09Merge branch 'pw/add-p-recount'Libravatar Junio C Hamano1-0/+8
"git checkout -p" needs to selectively apply a patch in reverse, which did not work well. * pw/add-p-recount: add -p: fix checkout -p with pathological context
2019-07-09Merge branch 'ds/commit-graph-write-refactor'Libravatar Junio C Hamano1-0/+8
Renamed from commit-graph-format-v2 and changed scope. * ds/commit-graph-write-refactor: commit-graph: extract write_commit_graph_file() commit-graph: extract copy_oids_to_commits() commit-graph: extract count_distinct_commits() commit-graph: extract fill_oids_from_all_packs() commit-graph: extract fill_oids_from_commit_hex() commit-graph: extract fill_oids_from_packs() commit-graph: create write_commit_graph_context commit-graph: remove Future Work section commit-graph: collapse parameters into flags commit-graph: return with errors during write commit-graph: fix the_repository reference
2019-07-09Merge branch 'sg/trace2-rename'Libravatar Junio C Hamano1-1/+0
Dev support update to help tracing out tests. * sg/trace2-rename: trace2: correct typo in technical documentation Revert "test-lib: whitelist GIT_TR2_* in the environment"
2019-07-09Merge branch 'js/mergetool-optim'Libravatar Junio C Hamano1-132/+177
"git mergetool" and its tests now spawn fewer subprocesses. * js/mergetool-optim: mergetool: use shell variable magic instead of `awk` mergetool: dissect strings with shell variable magic instead of `expr` t7610-mergetool: use test_cmp instead of test $(cat file) = $txt t7610-mergetool: do not place pipelines headed by `yes` in subshells
2019-07-09Merge branch 'tm/tag-gpgsign-config'Libravatar Junio C Hamano1-0/+21
A new tag.gpgSign configuration variable turns "git tag -a" into "git tag -s". * tm/tag-gpgsign-config: tag: add tag.gpgSign config option to force all tags be GPG-signed
2019-07-09Merge branch 'fc/fetch-with-import-fix'Libravatar Junio C Hamano2-13/+27
Code restructuring during 2.20 period broke fetching tags via "import" based transports. * fc/fetch-with-import-fix: fetch: fix regression with transport helpers fetch: make the code more understandable fetch: trivial cleanup t5801 (remote-helpers): add test to fetch tags t5801 (remote-helpers): cleanup refspec stuff
2019-07-09Merge branch 'nb/branch-show-other-worktrees-head'Libravatar Junio C Hamano3-7/+66
"git branch --list" learned to show branches that are checked out in other worktrees connected to the same repository prefixed with '+', similar to the way the currently checked out branch is shown with '*' in front. * nb/branch-show-other-worktrees-head: branch: add worktree info on verbose output branch: update output to include worktree info ref-filter: add worktreepath atom
2019-07-01rebase --am: ignore rebase.rescheduleFailedExecLibravatar Johannes Schindelin1-0/+8
The `exec` command is specific to the interactive backend, therefore it does not make sense for non-interactive rebases to heed that config setting. We still want to error out if a non-interactive rebase is started with `--reschedule-failed-exec`, of course. Reported by Vas Sudanagunta via: https://github.com/git/git/commit/969de3ff0e0#commitcomment-33257187 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-27t5551: test usage of chunked encoding explicitlyLibravatar Jonathan Tan1-3/+2
When run using GIT_TEST_PROTOCOL_VERSION=2, a test in t5551 fails because 4 POSTs (probe, ls-refs, probe, fetch) are sent instead of 2 (probe, fetch). One way to resolve this would be to relax the condition (from "= 2" to greater than 1, say), but upon further inspection, the test probably shouldn't be counting the number of POSTs. This test states that large requests are split across POSTs, but this is not correct; the main change is that chunked transfer encoding is used, but the request is still contained within one POST. (The test coincidentally works because Git indeed sends 2 POSTs in the case of a large request, but that is because, as stated above, the first POST is a probing RPC - see post_rpc() in remote-curl.c for more information.) Therefore, instead of counting POSTs, check that chunked transfer encoding is used. This also has the desirable side effect of passing with GIT_TEST_PROTOCOL_VERSION=2. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25t5551: use 'test_i18ngrep' to check translated outputLibravatar SZEDER Gábor1-2/+2
The two tests 'invalid Content-Type rejected' and 'server-side error detected' in 't5551-http-fetch-smart.sh' use "plain" 'grep' to check that 'git clone' failed with the expected error message, but the messages they are checking are translated, and, consequently, these tests fail when the test script is run with GIT_TEST_GETTEXT_POISON enabled. Use 'test_i18ngrep' instead. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25submodule foreach: fix recursion of optionsLibravatar Morian Sonnet1-0/+7
Calling git submodule foreach --recursive <subcommand> --<option> leads to an error stating that the option --<option> is unknown to submodule--helper. That is of course only, when <option> is not a valid option for git submodule foreach. The reason for this is, that above call is internally translated into a call to submodule--helper: git submodule--helper foreach --recursive \ -- <subcommand> --<option> This call starts by executing the subcommand with its option inside the first level submodule and continues by calling the next iteration of the submodule foreach call git --super-prefix <submodulepath> submodule--helper \ foreach --recursive <subcommand> --<option> inside the first level submodule. Note that the double dash in front of the subcommand is missing. This problem starts to arise only recently, as the PARSE_OPT_KEEP_UNKNOWN flag for the argument parsing of git submodule foreach was removed in commit a282f5a906. Hence, the unknown option is complained about now, as the argument parsing is not properly ended by the double dash. This commit fixes the problem by adding the double dash in front of the subcommand during the recursion. Signed-off-by: Morian Sonnet <moriansonnet@googlemail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@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-24t0001: fix on case-insensitive filesystemsLibravatar Johannes Schindelin2-14/+23
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible that the idea Bash has of the current directory differs in case from what Git thinks it is. That's totally okay, though, and we should not expect otherwise. On Windows, for example, when you call cd C:\GIT-SDK-64 in a PowerShell and there exists a directory called `C:\git-sdk-64`, the current directory will be reported in all upper-case. Even in a Bash that you might call from that PowerShell. Git, however, will have normalized this via `GetFinalPathByHandle()`, and the expectation in t0001 that the recorded gitdir will match what `pwd` says will be violated. Let's address this by comparing these paths in a case-insensitive manner when `core.ignoreCase` is `true`. Reported by Jameson Miller. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21tests: mark two failing tests under FAIL_PREREQSLibravatar Ævar Arnfjörð Bjarmason2-2/+2
Fix a couple of tests that would potentially fail under GIT_TEST_FAIL_PREREQS=true. I missed these when annotating other tests in dfe1a17df9 ("tests: add a special setup where prerequisites fail", 2019-05-13) because on my system I can only reproduce this failure when I run the tests as "root", since the tests happen to depend on whether we can fall back on GECOS info or not. I.e. they'd usually fail to look up the ident info anyway, but not always. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21Merge branch 'jt/partial-clone-missing-ref-delta-base'Libravatar Junio C Hamano1-13/+99
"git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected. * jt/partial-clone-missing-ref-delta-base: t5616: cover case of client having delta base t5616: use correct flag to check object is missing index-pack: prefetch missing REF_DELTA bases t5616: refactor packfile replacement
2019-06-21Merge branch 'ml/userdiff-rust'Libravatar Junio C Hamano5-0/+21
The pattern "git diff/grep" use to extract funcname and words boundary for Rust has been added. * ml/userdiff-rust: userdiff: two simplifications of patterns for rust userdiff: add built-in pattern for rust
2019-06-21fetch: add --[no-]show-forced-updates argumentLibravatar Derrick Stolee1-0/+23
After updating a set of remove refs during a 'git fetch', we walk the commits in the new ref value and not in the old ref value to discover if the update was a forced update. This results in two things happening during the command: 1. The line including the ref update has an additional "(forced-update)" marker at the end. 2. The ref log for that remote branch includes a bit saying that update is a forced update. For many situations, this forced-update message happens infrequently, or is a small bit of information among many ref updates. Many users ignore these messages, but the calculation required here slows down their fetches significantly. Keep in mind that they do not have the opportunity to calculate a commit-graph file containing the newly-fetched commits, so these comparisons can be very slow. Add a '--[no-]show-forced-updates' option that allows a user to skip this calculation. The only permanent result is dropping the forced-update bit in the reflog. Include a new fetch.showForcedUpdates config setting that allows this behavior without including the argument in every command. The config setting is overridden by the command-line arguments. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21status: ignore status.aheadbehind in porcelain formatsLibravatar Jeff Hostetler1-4/+8
Teach porcelain V[12] formats to ignore the status.aheadbehind config setting. They only respect the --[no-]ahead-behind command line argument. This is for backwards compatibility with existing scripts. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21status: add status.aheadbehind settingLibravatar Jeff Hostetler2-0/+35
The --[no-]ahead-behind option was introduced in fd9b544a (status: add --[no-]ahead-behind to status and commit for V2 format, 2018-01-09). This is a necessary change of behavior in repos where the remote tracking branches can move very quickly ahead of the local branches. However, users need to remember to provide the command-line argument every time. Add a new "status.aheadBehind" config setting to change the default behavior of all git status formats. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20t0001 (mingw): do not expect a specific order of stdout/stderrLibravatar Johannes Schindelin1-2/+2
When redirecting stdout/stderr to the same file, we cannot guarantee that stdout will come first. In fact, in this test case, it seems that an MSVC build always prints stderr first. In any case, this test case does not want to verify the *order* but the *presence* of both outputs, so let's test exactly that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20t2027: use test_must_be_emptyLibravatar Nguyễn Thái Ngọc Duy1-3/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20rev-list: teach --no-object-names to enable pipingLibravatar Emily Shaffer1-0/+20
Allow easier parsing by cat-file by giving rev-list an option to print only the OID of a non-commit object without any additional information. This is a short-term shim; later on, rev-list should be taught how to print the types of objects it finds in a format similar to cat-file's. Before this commit, the output from rev-list needed to be massaged before being piped to cat-file, like so: git rev-list --objects HEAD | cut -f 1 -d ' ' | git cat-file --batch-check This was especially unexpected when dealing with root trees, as an invisible whitespace exists at the end of the OID: git rev-list --objects --filter=tree:1 --max-count=1 HEAD | xargs -I% echo "AA%AA" Now, it can be piped directly, as in the added test case: git rev-list --objects --no-object-names HEAD | git cat-file --batch-check Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Change-Id: I489bdf0a8215532e540175188883ff7541d70e1b Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20object: convert lookup_unknown_object() to use object_idLibravatar Jeff King1-3/+3
There are no callers left of lookup_unknown_object() that aren't just passing us the "hash" member of a "struct object_id". Let's take the whole struct, which gets us closer to removing all raw sha1 variables. It also matches the existing conversions of lookup_blob(), etc. The conversions of callers were done by hand, but they're all mechanical one-liners. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-19fetch: only run 'gc' once when fetching multiple remotesLibravatar Nguyễn Thái Ngọc Duy1-2/+5
In multiple remotes mode, git-fetch is launched for n-1 remotes and the last remote is handled by the current process. Each of these processes will in turn run 'gc' at the end. This is not really a problem because even if multiple 'gc --auto' is run at the same time we still handle it correctly. It does show multiple "auto packing in the background" messages though. And we may waste some resources when gc actually runs because we still do some stuff before checking the lock and moving it to background. So let's try to avoid that. We should only need one 'gc' run after all objects and references are added anyway. Add a new option --no-auto-gc that will be used by those n-1 processes. 'gc --auto' will always run on the main fetch process (*). (*) even if we fetch remotes in parallel at some point in future, this should still be fine because we should "join" all those processes before this step. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-19stash: fix show referencing stash indexLibravatar Thomas Gummerer1-0/+18
In the conversion of 'stash show' to C in dc7bd382b1 ("stash: convert show to builtin", 2019-02-25), 'git stash show <n>', where n is the index of a stash got broken, if n is not a file or a valid revision by itself. 'stash show' accepts any flag 'git diff' accepts for changing the output format. Internally we use 'setup_revisions()' to parse these command line flags. Currently we pass the whole argv through to 'setup_revisions()', which includes the stash index. As the stash index is not a valid revision or a file in the working tree in most cases however, this 'setup_revisions()' call (and thus the whole command) ends up failing if we use this form of 'git stash show'. Instead of passing the whole argv to 'setup_revisions()', only pass the flags (and the command name) through, while excluding the stash reference. The stash reference is parsed (and validated) in 'get_stash_info()' already. This separate parsing also means that we currently do produce the correct output if the command succeeds. Reported-by: Mike Hommey <mh@glandium.org> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>