summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-12-08Merge branch 'fc/random-cleanup'Libravatar Junio C Hamano2-6/+6
Random cleanup. * fc/random-cleanup: gitignore: remove entry for git serve gitignore: drop duplicate entry for git-sh-i18n tests: lib-functions: trivial style cleanups test: completion: fix typos .gitignore: remove dangling file refspec: trivial cleanup
2020-12-08Merge branch 'rs/maintenance-run-outside-repo'Libravatar Junio C Hamano1-0/+8
"git maintenance run/start/stop" needed to be run in a repository to hold the lockfile they use, but didn't make sure they are actually in a repository, which has been corrected. * rs/maintenance-run-outside-repo: t7900: fix typo: "test_execpt_success" maintenance: fix SEGFAULT when no repository
2020-12-08Merge branch 'nk/perf-fsmonitor-cleanup'Libravatar Junio C Hamano1-2/+1
Test clean-up. * nk/perf-fsmonitor-cleanup: perf/fsmonitor: use test_must_be_empty helper
2020-12-08Merge branch 'js/trace2-session-id'Libravatar Junio C Hamano1-0/+78
The transport layer was taught to optionally exchange the session ID assigned by the trace2 subsystem during fetch/push transactions. * js/trace2-session-id: receive-pack: log received client session ID send-pack: advertise session ID in capabilities upload-pack, serve: log received client session ID fetch-pack: advertise session ID in capabilities transport: log received server session ID serve: advertise session ID in v2 capabilities receive-pack: advertise session ID in v0 capabilities upload-pack: advertise session ID in v0 capabilities trace2: add a public function for getting the SID docs: new transfer.advertiseSID option docs: new capability to advertise session IDs
2020-12-08Merge branch 'mt/do-not-use-scld-in-working-tree'Libravatar Junio C Hamano2-2/+28
"git apply" adjusted the permission bits of working-tree files and directories according core.sharedRepository setting by mistake and for a long time, which has been corrected. * mt/do-not-use-scld-in-working-tree: apply: don't use core.sharedRepository to create working tree files
2020-12-08Merge branch 'ds/maintenance-part-2'Libravatar Junio C Hamano1-2/+4
Test fix. * ds/maintenance-part-2: t7900: speed up expensive test
2020-12-08Merge branch 'ds/maintenance-part-3'Libravatar Junio C Hamano1-0/+12
"git maintenance" command had trouble working in a directory whose pathname contained an ERE metacharacter like '+'. * ds/maintenance-part-3: maintenance: use 'git config --fixed-value'
2020-12-08Merge branch 'ds/config-literal-value'Libravatar Junio C Hamano1-0/+149
Various subcommands of "git config" that takes value_regex learn the "--literal-value" option to take the value_regex option as a literal string. * ds/config-literal-value: config doc: value-pattern is not necessarily a regexp config: implement --fixed-value with --get* config: plumb --fixed-value into config API config: add --fixed-value option, un-implemented t1300: add test for --replace-all with value-pattern t1300: test "set all" mode with value-pattern config: replace 'value_regex' with 'value_pattern' config: convert multi_replace to flags
2020-12-08Merge branch 'tb/idx-midx-race-fix'Libravatar Junio C Hamano1-2/+28
Processes that access packdata while the .idx file gets removed (e.g. while repacking) did not fail or fall back gracefully as they could. * tb/idx-midx-race-fix: midx.c: protect against disappearing packs packfile.c: protect against disappearing indexes
2020-12-08Merge branch 'ps/update-ref-multi-transaction'Libravatar Junio C Hamano2-48/+110
"git update-ref --stdin" learns to take multiple transactions in a single session. * ps/update-ref-multi-transaction: update-ref: disallow "start" for ongoing transactions p1400: use `git-update-ref --stdin` to test multiple transactions update-ref: allow creation of multiple transactions t1400: avoid touching refs on filesystem
2020-12-08Merge branch 'js/add-i-color-fix'Libravatar Junio C Hamano1-0/+84
"git add -i" failed to honor custom colors configured to show patches, which has been corrected. * js/add-i-color-fix: add -i: verify in the tests that colors can be overridden add -p: prefer color.diff.context over color.diff.plain add -i (Perl version): color header to match the C version add -i (built-in): use the same indentation as the Perl version add -p (built-in): do not color the progress indicator separately add -i (built-in): use correct names to load color.diff.* config add -i (built-in): prevent the `reset` "color" from being configured add -i: use `reset_color` consistently add -p (built-in): imitate `xdl_format_hunk_hdr()` generating hunk headers add -i (built-in): send error messages to stderr add -i (built-in): do show an error message for incorrect inputs
2020-12-08t7900: fix typo: "test_execpt_success"Libravatar Josh Steadmon1-1/+1
Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03Merge branch 'pk/subsub-fetch-fix'Libravatar Junio C Hamano1-63/+0
An earlier attempt to fix "git fetch --recurse-submodules" broke another use case; revert it until a better fix is found. * pk/subsub-fetch-fix: Revert "submodules: fix of regression on fetching of non-init subsub-repo"
2020-12-03Merge branch 'pb/pull-rebase-recurse-submodules'Libravatar Junio C Hamano1-2/+54
"git pull --rebase --recurse-submodules" checked for local changes in a wrong range and failed to run correctly when it should. * pb/pull-rebase-recurse-submodules: pull: check for local submodule modifications with the right range t5572: describe '--rebase' tests a little more t5572: add notes on a peculiar test pull --rebase: compute rebase arguments in separate function
2020-12-02Revert "submodules: fix of regression on fetching of non-init subsub-repo"Libravatar Junio C Hamano1-63/+0
This reverts commit 1b7ac4e6d4d490b224f5206af7418ed74e490608; in <CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com>, Ralf Thielow reports that "git fetch" with submodule.recurse set can result in a bogus and infinitely recursive fetching of the same submodule.
2020-12-02apply: don't use core.sharedRepository to create working tree filesLibravatar Matheus Tavares2-2/+28
core.sharedRepository defines which permissions Git should set when creating files in $GIT_DIR, so that the repository may be shared with other users. But (in its current form) the setting shouldn't affect how files are created in the working tree. This is not respected by apply and am (which uses apply), when creating leading directories: $ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29 Apply without the setting: $ umask 0077 $ git apply d.patch $ ls -ld d drwx------ Apply with the setting: $ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws--- Only the leading directories are affected. That's because they are created with safe_create_leading_directories(), which calls adjust_shared_perm() to set the directories' permissions based on core.sharedRepository. To fix that, let's introduce a variant of this function that ignores the setting, and use it in apply. Also add a regression test and a note in the function documentation about the use of each variant according to the destination (working tree or git dir). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02t7900: speed up expensive testLibravatar Jeff King1-2/+4
A test marked with EXPENSIVE creates two 2.5GB files and adds them to the repository. This takes 194s to run on my machine, versus 2s when the EXPENSIVE prereq isn't set. We can trim this down a bit by doing two things: - use "git commit --quiet" to avoid spending time generating a diff summary (this actually only helps for the second commit, but I've added it here to both for consistency). This shaves off 8s. - set core.compression to 0. We know these files are full of random bytes, and so won't compress (that's the point of the test!). Spending cycles on zlib is pointless. This shaves off 122s. After this, my total time to run the script is 64s. That won't help normal runs without GIT_TEST_LONG set, of course, but it's easy enough to do. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01tests: lib-functions: trivial style cleanupsLibravatar Felipe Contreras1-4/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01test: completion: fix typosLibravatar Felipe Contreras1-2/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30Merge branch 'js/t3404-master-to-primary'Libravatar Junio C Hamano1-44/+45
A test script got cleaned up and then made not to depend on the value of init.defaultBranch. * js/t3404-master-to-primary: t3404: do not depend on any specific default branch name
2020-11-30Merge branch 'na/notes-displayref-is-not-boolean'Libravatar Junio C Hamano1-0/+5
Config parser fix for "git notes". * na/notes-displayref-is-not-boolean: t3301: test proper exit response to no-value notes.displayRef. notes.c: fix a segfault in notes_display_config()
2020-11-30Merge branch 'js/t1309-master-to-topic'Libravatar Junio C Hamano1-2/+2
Test preparation. * js/t1309-master-to-topic: t1309: use a neutral branch name in the `onbranch` test cases
2020-11-30Merge branch 'js/pull-rebase-use-advise'Libravatar Junio C Hamano1-2/+5
UI improvement. * js/pull-rebase-use-advise: pull: colorize the hint about setting `pull.rebase`
2020-11-30Merge branch 'js/t4015-wo-master'Libravatar Junio C Hamano1-3/+3
A test script got cleaned up not to depend on the value of init.defaultBranch. * js/t4015-wo-master: t4015: let the test pass with any default branch name
2020-11-30Merge branch 'js/t3040-cleanup'Libravatar Junio C Hamano1-3/+0
Cleanup. * js/t3040-cleanup: t3040: remove stale note
2020-11-30Merge branch 'js/t2106-cleanup'Libravatar Junio C Hamano1-14/+17
A test script got cleaned up and then made not to depend on the value of init.defaultBranch. * js/t2106-cleanup: t2106: ensure that the checkout fails for the expected reason t2106: make test independent of the current main branch name t2106: adjust style to the current conventions
2020-11-30perf/fsmonitor: use test_must_be_empty helperLibravatar Nipunn Koorapati1-2/+1
Simplify test and make error messages more clear here. Per feedback from Junio in 33226af42b (t/perf/fsmonitor: improve error message if typoing hook name, 2020-10-26) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30maintenance: fix SEGFAULT when no repositoryLibravatar Rafael Silva1-0/+8
The "git maintenance run" and "git maintenance start/stop" commands holds a file-based lock at the .git/maintenance.lock and .git/schedule.lock respectively. These locks are used to ensure only one maintenance process is executed at the time as both operations involves writing data into the git repository. The path to the lock file is built using "the_repository->objects->odb->path" that results in SEGFAULT when we have no repository available as "the_repository->objects->odb" is set to NULL. Let's teach maintenance command to use RUN_SETUP option that will provide the validation and fail when running outside of a repository. Hence fixing the SEGFAULT for all three operations and making the behaviour consistent across all subcommands. Setting the RUN_SETUP also provides the same protection for all subcommands given that the "register" and "unregister" also requires to be executed inside a repository. Furthermore let's remove the local validation implemented by the "register" and "unregister" as this will not be required anymore with the new option. Signed-off-by: Rafael Silva <rafaeloliveira.cs@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25Merge branch 'sg/tests-prereq'Libravatar Junio C Hamano2-4/+25
A lazily defined test prerequisite can now be defined in terms of another lazily defined test prerequisite. * sg/tests-prereq: tests: fix description of 'test_set_prereq' tests: make sure nested lazy prereqs work reliably
2020-11-25Merge branch 'sg/t5310-jgit-wants-sha1'Libravatar Junio C Hamano1-2/+2
Since jgit does not yet work with SHA-256 repositories, mark the tests that uses it not to run unless we are testing with ShA-1 repositories. * sg/t5310-jgit-wants-sha1: t5310-pack-bitmaps: skip JGit tests with SHA256
2020-11-25Merge branch 'pk/subsub-fetch-fix'Libravatar Junio C Hamano1-0/+63
"git fetch" did not work correctly with nested submodules where the innermost submodule that is not of interest got updated in the upstream, which has been corrected. * pk/subsub-fetch-fix: submodules: fix of regression on fetching of non-init subsub-repo
2020-11-25Merge branch 'jx/t5411-flake-fix'Libravatar Junio C Hamano8-42/+476
The exchange between receive-pack and proc-receive hook did not carefully check for errors. * jx/t5411-flake-fix: receive-pack: use default version 0 for proc-receive receive-pack: gently write messages to proc-receive t5411: new helper filter_out_user_friendly_and_stable_output
2020-11-25Merge branch 'fc/bash-completion-alias-of-alias'Libravatar Junio C Hamano1-0/+19
The command line completion script (in contrib/) learned to expand commands that are alias of alias. * fc/bash-completion-alias-of-alias: completion: bash: improve alias loop detection completion: bash: check for alias loop completion: bash: support recursive aliases
2020-11-25maintenance: use 'git config --fixed-value'Libravatar Derrick Stolee1-0/+12
When a repository's leading directories contain regex metacharacters, the config calls for 'git maintenance register' and 'git maintenance unregister' are not careful enough. Use the new --fixed-value option to direct the config machinery to use exact string matches. This is a more robust option than escaping these arguments in a piecemeal fashion. For the test, require that we are not running on Windows since the '+' and '*' characters are not allowed on that filesystem. Reported-by: Emily Shaffer <emilyshaffer@google.com> Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: implement --fixed-value with --get*Libravatar Derrick Stolee1-0/+22
The config builtin does its own regex matching of values for the --get, --get-all, and --get-regexp modes. Plumb the existing 'flags' parameter to the get_value() method so we can initialize the value-pattern argument as a fixed string instead of a regex pattern. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: plumb --fixed-value into config APILibravatar Derrick Stolee1-0/+50
The git_config_set_multivar_in_file_gently() and related methods now take a 'flags' bitfield, so add a new bit representing the --fixed-value option from 'git config'. This alters the purpose of the value_pattern parameter to be an exact string match. This requires some initialization changes in git_config_set_multivar_in_file_gently() and a new strcmp() call in the matches() method. The new CONFIG_FLAGS_FIXED_VALUE flag is initialized in builtin/config.c based on the --fixed-value option, and that needs to be updated in several callers. This patch only affects some of the modes of 'git config', and the rest will be completed in the next change. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: add --fixed-value option, un-implementedLibravatar Derrick Stolee1-0/+24
The 'git config' builtin takes a 'value-pattern' parameter for several actions. This can cause confusion when expecting exact value matches instead of regex matches, especially when the input string contains metacharacters. While callers can escape the patterns themselves, it would be more friendly to allow an argument to disable the pattern matching in favor of an exact string match. Add a new '--fixed-value' option that does not currently change the behavior. The implementation will be filled in by later changes for each appropriate action. For now, check and test that --fixed-value will abort the command when included with an incompatible action or without a 'value-pattern' argument. The name '--fixed-value' was chosen over something simpler like '--fixed' because some commands allow regular expressions on the key in addition to the value. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: add test for --replace-all with value-patternLibravatar Derrick Stolee1-0/+14
The --replace-all option was added in 4ddba79d (git-config-set: add more options) but was not tested along with the 'value-pattern' parameter. Since we will be updating this option to optionally treat 'value-pattern' as a fixed string, let's add a test here that documents the current behavior. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: test "set all" mode with value-patternLibravatar Derrick Stolee1-0/+39
Without additional modifiers, 'git config <key> <value>' attempts to set a single value in the .git/config file. When the value-pattern parameter is supplied, this command behaves in a non-trivial manner. Consider 'git config <key> <value> <value-pattern>'. The expected behavior is as follows: 1. If there are multiple existing values that match 'value-pattern', then the command fails. Users should use --replace-all instead. 2. If there is no existing values match 'value-pattern', then the 'key=value' pair is appended, making this 'key' a multi-valued config setting. 3. If there is one existing value that matches 'value-pattern', then the new config has one entry where 'key=value'. Add a test that demonstrates these options. Break from the existing pattern in t1300-config.sh to use 'git config --file=<file>' instead of modifying .git/config directly to prevent possibly incompatible repo states. Also use 'git config --file=<file> --list' for config state comparison instead of the config file format. This makes the tests more readable. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25midx.c: protect against disappearing packsLibravatar Taylor Blau1-1/+7
When a packed object is stored in a multi-pack index, but that pack has racily gone away, the MIDX code simply calls die(), when it could be returning an error to the caller, which would in turn lead to re-scanning the pack directory. A pack can racily disappear, for example, due to a simultaneous 'git repack -ad', You can also reproduce this with two terminals, where one is running: git init while true; do git commit -q --allow-empty -m foo git repack -ad git multi-pack-index write done (in effect, constantly writing new MIDXs), and the other is running: obj=$(git rev-parse HEAD) while true; do echo $obj | git cat-file --batch-check='%(objectsize:disk)' || break done That will sometimes hit the error preparing packfile from multi-pack-index message, which this patch fixes. Right now, that path to discovering a missing pack looks something like 'find_pack_entry()' calling 'fill_midx_entry()' and eventually making its way to call 'nth_midxed_pack_entry()'. 'nth_midxed_pack_entry()' already checks 'is_pack_valid()' and propagates an error if the pack is invalid. So, this works if the pack has gone away between calling 'prepare_midx_pack()' and before calling 'is_pack_valid()', but not if it disappears before then. Catch the case where the pack has already disappeared before 'prepare_midx_pack()' by returning an error in that case, too. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25packfile.c: protect against disappearing indexesLibravatar Taylor Blau1-2/+22
In 17c35c8969 (packfile: skip loading index if in multi-pack-index, 2018-07-12) we stopped loading the .idx file for packs that are contained within a multi-pack index. This saves us the effort of loading an .idx and doing some lightweight validity checks by way of 'packfile.c:load_idx()', but introduces a race between processes that need to load the index (e.g., to generate a reverse index) and processes that can delete the index. For example, running the following in your shell: $ git init repo && cd repo $ git commit --allow-empty -m 'base' $ git repack -ad && git multi-pack-index write followed by: $ rm -f .git/objects/pack/pack-*.idx $ git rev-parse HEAD | git cat-file --batch-check='%(objectsize:disk)' will result in a segfault prior to this patch. What's happening here is that we notice that the pack is in the multi-pack index, and so don't check that it still has a .idx. When we then try and load that index to generate a reverse index, we don't have it, so the call to 'find_pack_revindex()' in 'packfile.c:packed_object_info()' returns NULL, and then dereferencing it causes a segfault. Of course, we don't ever expect someone to remove the index file by hand, or to be in a state where we never wrote it to begin with (yet find that pack in the multi-pack-index). But, this can happen in a timing race with 'git repack -ad', which removes all existing packs after writing a new pack containing all of their objects. Avoid this by reverting the hunk of 17c35c8969 which stops loading the index when the pack is contained in a MIDX. This makes the latter half of 17c35c8969 useless, since we'll always have a non-NULL 'p->index_data', in which case that if statement isn't guarding anything. These two together effectively revert 17c35c8969, and avoid the race explained above. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-24t3404: do not depend on any specific default branch nameLibravatar Johannes Schindelin1-44/+45
Now that we can override the default branch name in the tests via `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME`, we should avoid expecting a particular hard-coded name. So let's rename the initial branch immediately to `primary` and work with that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-23t3301: test proper exit response to no-value notes.displayRef.Libravatar Nate Avers1-0/+5
Signed-off-by: Nate Avers <nate@roosteregg.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-21Merge branch 'en/strmap'Libravatar Junio C Hamano1-5/+4
A specialization of hashmap that uses a string as key has been introduced. Hopefully it will see wider use over time. * en/strmap: shortlog: use strset from strmap.h Use new HASHMAP_INIT macro to simplify hashmap initialization strmap: take advantage of FLEXPTR_ALLOC_STR when relevant strmap: enable allocations to come from a mem_pool strmap: add a strset sub-type strmap: split create_entry() out of strmap_put() strmap: add functions facilitating use as a string->int map strmap: enable faster clearing and reusing of strmaps strmap: add more utility functions strmap: new utility functions hashmap: provide deallocation function names hashmap: introduce a new hashmap_partial_clear() hashmap: allow re-use after hashmap_free() hashmap: adjust spacing to fix argument alignment hashmap: add usage documentation explaining hashmap_free[_entries]()
2020-11-21Merge branch 'jk/diff-release-filespec-fix'Libravatar Junio C Hamano1-0/+13
Running "git diff" while allowing external diff in a state with unmerged paths used to segfault, which has been corrected. * jk/diff-release-filespec-fix: t7800: simplify difftool test diff: allow passing NULL to diff_free_filespec_data()
2020-11-21Merge branch 'jk/rev-parse-end-of-options'Libravatar Junio C Hamano2-0/+38
"git rev-parse" learned the "--end-of-options" to help scripts to safely take a parameter that is supposed to be a revision, e.g. "git rev-parse --verify -q --end-of-options $rev". * jk/rev-parse-end-of-options: rev-parse: handle --end-of-options rev-parse: put all options under the "-" check rev-parse: don't accept options after dashdash
2020-11-21Merge branch 'jc/format-patch-name-max'Libravatar Junio C Hamano1-0/+54
The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * jc/format-patch-name-max: format-patch: make output filename configurable
2020-11-19pull: colorize the hint about setting `pull.rebase`Libravatar Johannes Schindelin1-2/+5
In d18c950a69f (pull: warn if the user didn't say whether to rebase or to merge, 2020-03-09), a new hint was introduced to encourage users to make a conscious decision about whether they want their pull to merge or to rebase by configuring the `pull.rebase` setting. This warning was clearly intended to advise users, but as pointed out in https://lore.kernel.org/git/87ima2rdsm.fsf%40evledraar.gmail.com, it uses `warning()` instead of `advise()`. One consequence is that the advice is not colorized in the same manner as other, similar messages. So let's use `advise()` instead. Pointed-out-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t4015: let the test pass with any default branch nameLibravatar Johannes Schindelin1-3/+3
We do not need to hard-code the actual branch name, as we can use the `test_commit` function to simplify the code and use the tag it generates, thereby being a lot more precise in what we want. Strangely enough, this test case would have succeeded even with an overridden default branch name, obviously for the wrong reason. Let's verify that it passes for the expected reason, by looking for a tell-tale in Git's output. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t1309: use a neutral branch name in the `onbranch` test casesLibravatar Johannes Schindelin1-2/+2
The `onbranch` test cases touched by this patch do not actually try to include any other config. Their purpose is to avoid regressing on two bugs in the `include.onbranch:<name>.path` code that we fixed in the past, bugs that are actually unrelated to any concrete branch name. The first bug was fixed in 85fe0e800ca (config: work around bug with includeif:onbranch and early config, 2019-07-31). Essentially, when reading early config, there would be a catch-22 trying to access the refs, and therefore we simply cannot evaluate the condition at that point. The test case ensures that we avoid emitting this bogus message: BUG: refs.c:1851: attempting to get main_ref_store outside of repository The second test case concerns the non-Git scenario, where we simply do not have a current branch to begin with (because we don't have a repository in the first place), and the test case was introduced in 22932d9169f (config: stop checking whether the_repository is NULL, 2019-08-06) to ensure that we don't cause a segmentation fault should the code still incorrectly try to look at any ref. In short, neither of these two test cases will ever look at a current branch name, even in case of regressions. Therefore, the actual branch name does not matter at all. We can therefore easily avoid racially-charged branch names here, and that's what this patch does. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>