summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12Merge branch 'jc/trivial-threeway-binary-merge' into maintLibravatar Junio C Hamano1-0/+45
The "git apply -3" code path learned not to bother the lower level merge machinery when the three-way merge can be trivially resolved without the content level merge. * jc/trivial-threeway-binary-merge: apply: resolve trivial merge without hitting ll-merge with "--3way"
2021-10-12Merge branch 'ab/send-email-config-fix' into maintLibravatar Junio C Hamano1-0/+15
Regression fix. * ab/send-email-config-fix: send-email: fix a "first config key wins" regression in v2.33.0
2021-10-12Merge branch 'jk/log-warn-on-bogus-encoding' into maintLibravatar Junio C Hamano1-0/+7
Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails
2021-10-12Merge branch 'tk/fast-export-anonymized-tag-fix' into maintLibravatar Junio C Hamano1-4/+6
The output from "git fast-export", when its anonymization feature is in use, showed an annotated tag incorrectly. * tk/fast-export-anonymized-tag-fix: fast-export: fix anonymized tag using original length
2021-10-12Merge branch 'mh/send-email-reset-in-reply-to' into maintLibravatar Junio C Hamano1-0/+45
Even when running "git send-email" without its own threaded discussion support, a threading related header in one message is carried over to the subsequent message to result in an unwanted threading, which has been corrected. * mh/send-email-reset-in-reply-to: send-email: avoid incorrect header propagation
2021-10-12Merge branch 'sg/set-ceiling-during-tests' into maintLibravatar Junio C Hamano1-1/+2
Buggy tests could damage repositories outside the throw-away test area we created. We now by default export GIT_CEILING_DIRECTORIES to limit the damage from such a stray test. * sg/set-ceiling-during-tests: test-lib: set GIT_CEILING_DIRECTORIES to protect the surrounding repository
2021-10-12Merge branch 'ka/want-ref-in-namespace' into maintLibravatar Junio C Hamano1-36/+172
"git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper
2021-10-12Merge branch 'sg/column-nl' into maintLibravatar Junio C Hamano1-0/+18
The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option
2021-10-12Merge branch 'rs/branch-allow-deleting-dangling' into maintLibravatar Junio C Hamano1-0/+13
"git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force
2021-10-12Merge branch 'mt/quiet-with-delayed-checkout' into maintLibravatar Junio C Hamano1-0/+71
The delayed checkout code path in "git checkout" etc. were chatty even when --quiet and/or --no-progress options were given. * mt/quiet-with-delayed-checkout: checkout: make delayed checkout respect --quiet and --no-progress
2021-10-12Merge branch 'dd/diff-files-unmerged-fix' into maintLibravatar Junio C Hamano1-0/+53
"git diff --relative" segfaulted and/or produced incorrect result when there are unmerged paths. * dd/diff-files-unmerged-fix: diff-lib: ignore paths that are outside $cwd if --relative asked
2021-10-12Merge branch 'pw/rebase-r-fixes' into maintLibravatar Junio C Hamano3-9/+98
Various bugs in "git rebase -r" have been fixed. * pw/rebase-r-fixes: rebase -r: fix merge -c with a merge strategy rebase -r: don't write .git/MERGE_MSG when fast-forwarding rebase -i: add another reword test rebase -r: make 'merge -c' behave like reword
2021-10-12Merge branch 'pw/rebase-skip-final-fix' into maintLibravatar Junio C Hamano2-6/+25
Checking out all the paths from HEAD during the last conflicted step in "git rebase" and continuing would cause the step to be skipped (which is expected), but leaves MERGE_MSG file behind in $GIT_DIR and confuses the next "git commit", which has been corrected. * pw/rebase-skip-final-fix: rebase --continue: remove .git/MERGE_MSG rebase --apply: restore some tests t3403: fix commit authorship
2021-10-12Merge branch 'jk/commit-edit-fixup-fix' into maintLibravatar Junio C Hamano1-1/+8
"git commit --fixup" now works with "--edit" again, after it was broken in v2.32. * jk/commit-edit-fixup-fix: commit: restore --edit when combined with --fixup
2021-10-12Merge branch 'jk/apply-binary-hunk-parsing-fix' into maintLibravatar Junio C Hamano1-0/+23
"git apply" miscounted the bytes and failed to read to the end of binary hunks. * jk/apply-binary-hunk-parsing-fix: apply: keep buffer/size pair in sync when parsing binary hunks
2021-10-12Merge branch 'en/pull-conflicting-options' into maintLibravatar Junio C Hamano11-62/+266
"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options
2021-10-12Merge branch 'jt/push-negotiation-fixes' into maintLibravatar Junio C Hamano3-1/+88
Bugfix for common ancestor negotiation recently introduced in "git push" codepath. * jt/push-negotiation-fixes: fetch: die on invalid --negotiation-tip hash send-pack: fix push nego. when remote has refs send-pack: fix push.negotiate with remote helper
2021-10-12Merge branch 'ab/pack-stdin-packs-fix' into maintLibravatar Junio C Hamano1-0/+104
Input validation of "git pack-objects --stdin-packs" has been corrected. * ab/pack-stdin-packs-fix: pack-objects: fix segfault in --stdin-packs option pack-objects tests: cover blindspots in stdin handling
2021-10-12Merge branch 'cb/plug-leaks-in-alloca-emu-users' into maintLibravatar Junio C Hamano1-11/+12
Leakfix. * cb/plug-leaks-in-alloca-emu-users: t0000: avoid masking git exit value through pipes tree-diff: fix leak when not HAVE_ALLOCA_H
2021-10-12Merge branch 'jk/t5562-racefix' into maintLibravatar Junio C Hamano1-8/+8
Test update. * jk/t5562-racefix: t5562: use alarm() to interrupt timed child-wait
2021-10-12Merge branch 'dd/t6300-wo-gpg-fix' into maintLibravatar Junio C Hamano1-11/+18
Test fix. * dd/t6300-wo-gpg-fix: t6300: check for cat-file exit status code t6300: don't run cat-file on non-existent object
2021-10-12Merge branch 'jk/t5323-no-pack-test-fix' into maintLibravatar Junio C Hamano1-2/+2
Test fix. * jk/t5323-no-pack-test-fix: t5323: drop mentions of "master"
2021-10-12Merge branch 'js/maintenance-launchctl-fix' into maintLibravatar Junio C Hamano1-0/+17
"git maintenance" scheduler fix for macOS. * js/maintenance-launchctl-fix: maintenance: skip bootout/bootstrap when plist is registered maintenance: create `launchctl` configuration using a lock file
2021-10-12Merge branch 'ab/ls-remote-packet-trace' into maintLibravatar Junio C Hamano1-3/+3
Debugging aid fix. * ab/ls-remote-packet-trace: ls-remote: set packet_trace_identity(<name>)
2021-10-12Merge branch 'ga/send-email-sendmail-cmd' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * ga/send-email-sendmail-cmd: t9001: PATH must not use Windows-style paths
2021-10-12Merge branch 'me/t5582-cleanup' into maintLibravatar Junio C Hamano1-1/+0
Test fix. * me/t5582-cleanup: t5582: remove spurious 'cd "$D"' line
2021-10-12Merge branch 'fc/completion-updates' into maintLibravatar Junio C Hamano1-0/+15
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-10-12Merge branch 'js/log-protocol-version' into maintLibravatar Junio C Hamano1-0/+11
Debugging aid. * js/log-protocol-version: connect, protocol: log negotiated protocol version
2021-09-16t0000: avoid masking git exit value through pipesLibravatar Carlo Marcelo Arenas Belón1-11/+12
9af0b8dbe2 (t0000-basic: more commit-tree tests., 2006-04-26) adds tests for commit-tree that mask the return exit from git as described in a378fee5b07 (Documentation: add shell guidelines, 2018-10-05). Fix the tests, to avoid pipes by using a temporary file instead. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09t5562: use alarm() to interrupt timed child-waitLibravatar Jeff King1-8/+8
The t5562 script occasionally takes 60 extra seconds to complete due to a race condition in the invoke-with-content-length.pl helper. The way it's supposed to work is this: - we set up a SIGCLD handler - we kick off http-backend and write to it with a set content-length, but _don't_ close the pipe - we sleep for 60 seconds, assuming that SIGCLD from http-backend finishing will interrupt us - after the sleep finishes (whetherby 60 seconds or because it was interrupted by the signal), we check a flag to see if our SIGCLD handler was called. If not, then we complain. This usually completes immediately, because the signal interrupts our sleep. But very occasionally the child process dies _before_ we hit the sleep, so we don't realize it. The test still completes successfully (because our $exited flag is set), but it takes an extra 60 seconds. There's no way to check the flag and sleep atomically. So the best we can do with this approach is to sleep in smaller chunks (say, 1 second) and check the flag incrementally. Then we waste a maximum of 1 second if we lose the race. This was proposed in: https://lore.kernel.org/git/20190218205028.32486-1-max@max630.net/ and it does work. But we can do better. Instead of blocking on sleep and waiting for the child signal to interrupt us, we can block on the child exiting and set an alarm signal to trigger the timeout. This lets us exit the script immediately when the child behaves (with no race possible), and wait a maximum of 60 seconds when it doesn't. Note one small subtlety: perl is very willing to restart the waitpid() call after the alarm is delivered, even if we've thrown an exception via die. "perldoc -f alarm" claims you can get around this with an eval/die combo (and even has some example code), but it doesn't seem to work for me with waitpid(); instead, we continue waiting until the child exits. So instead, we'll instruct the child process to exit in the alarm handler itself. In the original code this was done by calling close($out). That would continue to work, since our child is always http-backend, which should exit when its stdin closes. But we can be even more robust against a hung or confused child by sending a KILL signal, which should terminate it immediately. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07send-email: fix a "first config key wins" regression in v2.33.0Libravatar Ævar Arnfjörð Bjarmason1-0/+15
Fix a regression in my c95e3a3f0b8 (send-email: move trivial config handling to Perl, 2021-05-28) where we'd pick the first config key out of multiple defined ones, instead of using the normal "last key wins" semantics of "git config --get". This broke e.g. cases where a .git/config would have a different sendemail.smtpServer than ~/.gitconfig. We'd pick the ~/.gitconfig over .git/config, instead of preferring the repository-local version. The same would go for /etc/gitconfig etc. The full list of impacted config keys (the %config_settings values which are references to scalars, not arrays) is: sendemail.smtpencryption sendemail.smtpserver sendemail.smtpserverport sendemail.smtpuser sendemail.smtppass sendemail.smtpdomain sendemail.smtpauth sendemail.smtpbatchsize sendemail.smtprelogindelay sendemail.tocmd sendemail.cccmd sendemail.aliasfiletype sendemail.envelopesender sendemail.confirm sendemail.from sendemail.assume8bitencoding sendemail.composeencoding sendemail.transferencoding sendemail.sendmailcmd I.e. having any of these set in say ~/.gitconfig and in-repo .git/config regressed in v2.33.0 to prefer the --global one over the --local. To test this add a test of config priority to one of these config variables, most don't have tests at all, but there was an existing one for sendemail.8bitEncoding. The "git config" (instead of "test_config") is somewhat of an anti-pattern, but follows established conventions in t9001-send-email.sh, likewise with any other pattern or idiom in this test. The populating of home/.gitconfig and setting of HOME= is copied from a test in t0017-env-helper.sh added in 1ff750b128e (tests: make GIT_TEST_GETTEXT_POISON a boolean, 2019-06-21). This test fails without this bugfix, but now it works. Reported-by: Eli Schwartz <eschwartz@archlinux.org> Tested-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-05apply: resolve trivial merge without hitting ll-merge with "--3way"Libravatar Junio C Hamano1-0/+45
The ll_binary_merge() function assumes that the ancestor blob is different from either side of the new versions, and always fails the merge in conflict, unless -Xours or -Xtheirs is in effect. The normal "merge" machineries all resolve the trivial cases (e.g. if our side changed while their side did not, the result is ours) without triggering the file-level merge drivers, so the assumption is warranted. The code path in "git apply --3way", however, does not check for the trivial three-way merge situation and always calls the file-level merge drivers. This used to be perfectly OK back when we always first attempted a straight patch application and used the three-way code path only as a fallback. Any binary patch that can be applied as a trivial three-way merge (e.g. the patch is based exactly on the version we happen to have) would always cleanly apply, so the ll_binary_merge() that is not prepared to see the trivial case would not have to handle such a case. This no longer is true after we made "--3way" to mean "first try three-way and then fall back to straight application", and made "git apply -3" on a binary patch that is based on the current version no longer apply. Teach "git apply -3" to first check for the trivial merge cases and resolve them without hitting the file-level merge drivers. Signed-off-by: Jerry Zhang <jerry@skydio.com> [jc: stolen tests from Jerry's patch] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-01upload-pack.c: treat want-ref relative to namespaceLibravatar Kim Altintop1-0/+135
When 'upload-pack' runs within the context of a git namespace, treat any 'want-ref' lines the client sends as relative to that namespace. Also check if the wanted ref is hidden via 'hideRefs'. If it is hidden, respond with an error as if the ref didn't exist. Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Kim Altintop <kim@eagain.st> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-01t5730: introduce fetch command helperLibravatar Kim Altintop1-36/+37
Assembling a "raw" fetch command to be fed directly to "test-tool serve-v2" is extracted into a test helper. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Kim Altintop <kim@eagain.st> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-31fast-export: fix anonymized tag using original lengthLibravatar Tal Kelrich1-4/+6
Commit 7f4075949686 (fast-export: tighten anonymize_mem() interface to handle only strings, 2020-06-23) changed the interface used in anonymizing strings, but failed to update the size of annotated tag messages to match the new anonymized string. As a result, exporting tags having messages longer than 13 characters would create output that couldn't be parsed by fast-import, as the data length indicated was larger than the data output. Reset the message size when anonymizing, and add a tag with a "long" message to the test. Signed-off-by: Tal Kelrich <hasturkun@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-30send-email: avoid incorrect header propagationLibravatar Marvin Häuser1-0/+45
If multiple independent patches are sent with send-email, even if the "In-Reply-To" and "References" headers are not managed by --thread or --in-reply-to, their values may be propagated from prior patches to subsequent patches with no such headers defined. To mitigate this and potential future issues, make sure all global patch-specific variables are always either handled by command-specific code (e.g. threading), or are reset to their default values for every iteration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Marvin Häuser <mhaeuser@posteo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-30test-lib: set GIT_CEILING_DIRECTORIES to protect the surrounding repositoryLibravatar SZEDER Gábor1-1/+2
Every once in a while a test somehow manages to escape from its trash directory and modifies the surrounding repository, whether because of a bug in git itself, a bug in a test [1], or e.g. when trying to run tests with a shell that is, in general, unable to run our tests [2]. Set GIT_CEILING_DIRECTORIES="$TRASH_DIRECTORY/.." as an additional safety measure to protect the surrounding repository at least from modifications by git commands executed in the tests (assuming that handling of ceiling directories during repository discovery is not broken, and, of course, it won't save us from regular shell commands, e.g. 'cd .. && rm -f ...'). [1] e.g. https://public-inbox.org/git/20210423051255.GD2947267@szeder.dev [2] $ git symbolic-ref HEAD refs/heads/master $ ksh ./t2011-checkout-invalid-head.sh [... a lot of "not ok" ...] $ git symbolic-ref HEAD refs/heads/other (In short: 'ksh' doesn't support the 'local' builtin command, which is used by 'test_oid', causing it to return with error whenever it's called, leaving ZERO_OID set to empty, so when the test 'checkout main from invalid HEAD' runs 'echo $ZERO_OID >.git/HEAD' it writes a corrupt (not invalid) HEAD, and subsequent git commands don't recognize the repository in the trash directory anymore, but operate on the surrounding repo.) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27branch: allow deleting dangling branches with --forceLibravatar René Scharfe1-0/+13
git branch only allows deleting branches that point to valid commits. Skip that check if --force is given, as the caller is indicating with it that they know what they are doing and accept the consequences. This allows deleting dangling branches, which previously had to be reset to a valid start-point using --force first. Reported-by: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27logmsg_reencode(): warn when iconv() failsLibravatar Jeff King1-0/+7
If the user asks for a pretty-printed commit to be converted (either explicitly with --encoding=foo, or implicitly because the commit is non-utf8 and we want to convert it), we pass it through iconv(). If that fails, we fall back to showing the input verbatim, but don't tell the user that the output may be bogus. Let's add a warning to do so, along with a mention in the documentation for --encoding. Two things to note about the implementation: - we could produce the warning closer to the call to iconv() in reencode_string_len(), which would let us relay the value of errno. But this is not actually very helpful. reencode_string_len() does not know we are operating on a commit, and indeed does not know that the caller won't produce an error of its own. And the errno values from iconv() are seldom helpful (iconv_open() only ever produces EINVAL; perhaps EILSEQ from iconv() might be illuminating, but it can also return EINVAL for incomplete sequences). - if the reason for the failure is that the output charset is not supported, then the user will see this warning for every commit we try to display. That might be ugly and overwhelming, but on the other hand it is making it clear that every one of them has not been converted (and the likely outcome anyway is to re-try the command with a supported output encoding). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26checkout: make delayed checkout respect --quiet and --no-progressLibravatar Matheus Tavares1-0/+71
The 'Filtering contents...' progress report from delayed checkout is displayed even when checkout and clone are invoked with --quiet or --no-progress. Furthermore, it is displayed unconditionally, without first checking whether stdout is a tty. Let's fix these issues and also add some regression tests for the two code paths that currently use delayed checkout: unpack_trees.c:check_updates() and builtin/checkout.c:checkout_worktree(). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26column: fix parsing of the '--nl' optionLibravatar SZEDER Gábor1-0/+18
'git column's '--nl' option can be used to specify a "string to be printed at the end of each line" (quoting the man page), but this option and its mandatory argument has been parsed as OPT_INTEGER since the introduction of the command in 7e29b8254f (Add column layout skeleton and git-column, 2012-04-21). Consequently, any non-number argument is rejected by parse-options, and any number other than 0 leads to segfault: $ printf "%s\n" one two |git column --mode=plain --nl=foo error: option `nl' expects a numerical value $ printf "%s\n" one two |git column --mode=plain --nl=42 Segmentation fault (core dumped) $ printf "%s\n" one two |git column --mode=plain --nl=0 one two Parse this option as OPT_STRING. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-25diff-lib: ignore paths that are outside $cwd if --relative askedLibravatar Đoàn Trần Công Danh1-0/+53
For diff family commands, we can tell them to exclude changes outside of some directories if --relative is requested. In diff_unmerge(), NULL will be returned if the requested path is outside of the interesting directories, thus we'll run into NULL pointer dereference in run_diff_files when trying to dereference its return value. Checking for return value of diff_unmerge before dereferencing is not sufficient, though. Since, diff engine will try to work on such pathspec later. Let's not run diff on those unintesting entries, instead. As a side effect, by skipping like that, we can save some CPU cycles. Reported-by: Thomas De Zeeuw <thomas@slight.dev> Tested-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-25t6300: check for cat-file exit status codeLibravatar Đoàn Trần Công Danh1-1/+3
In test_atom(), we're piping the output of cat-file to tail(1), thus, losing its exit status. Let's use a temporary file to preserve git exit status code. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-25t6300: don't run cat-file on non-existent objectLibravatar Đoàn Trần Công Danh1-11/+16
In t6300, some tests are guarded behind some prerequisites. Thus, objects created by those tests ain't available if those prerequisites are unsatistified. Attempting to run "cat-file" on those objects will run into failure. In fact, running t6300 in an environment without gpg(1), we'll see those warnings: fatal: Not a valid object name refs/tags/signed-empty fatal: Not a valid object name refs/tags/signed-short fatal: Not a valid object name refs/tags/signed-long Let's put those commands into the real tests, in order to: * skip their execution if prerequisites aren't satistified. * check their exit status code The expected value for objects with type: commit needs to be computed outside the test because we can't rely on "$3" there. Furthermore, to prevent the accidental usage of that computed expected value, BUG out on unknown object's type. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-25t5323: drop mentions of "master"Libravatar Jeff King1-2/+2
Commit 0696232390 (pack-redundant: fix crash when one packfile in repo, 2020-12-16) added one some new tests to t5323. At the time, the sub-repo we used was called "master". But in a parallel branch, this was switched to "main". When the latter branch was merged in 27d7c8599b (Merge branch 'js/default-branch-name-tests-final-stretch', 2021-01-25), some of those spots caused textual conflicts, but some (for tests that were far enough away from other changed code) were just semantic. The merge resolution fixed up most spots, but missed this one. Even though this did impact actual code, it turned out not to fail the tests. Running 'cd "$master_repo"' ended up staying in the same directory, running the test in the main trash repo instead of the sub-repo. But because the point of the test is checking behavior when there are no packfiles, it worked in either repo (since both are empty at this point in the script). Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24ls-remote: set packet_trace_identity(<name>)Libravatar Ævar Arnfjörð Bjarmason1-3/+3
Set packet_trace_identity() for ls-remote. This replaces the generic "git" identity in GIT_TRACE_PACKET=<file> traces to "ls-remote", e.g.: [...] packet: upload-pack> version 2 [...] packet: upload-pack> agent=git/2.32.0-dev [...] packet: ls-remote< version 2 [...] packet: ls-remote< agent=git/2.32.0-dev Where in an "git ls-remote file://<path>" dialog ">" is the sender (or "to the server") and "<" is the recipient (or "received by the client"). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24maintenance: skip bootout/bootstrap when plist is registeredLibravatar Derrick Stolee1-0/+17
On macOS, we use launchctl to manage the background maintenance schedule. This uses a set of .plist files to describe the schedule, but these files are also registered with 'launchctl bootstrap'. If multiple 'git maintenance start' commands run concurrently, then they can collide replacing these schedule files and registering them with launchctl. To avoid extra launchctl commands, do a check for the .plist files on disk and check if they are registered using 'launchctl list <name>'. This command will return with exit code 0 if it exists, or exit code 113 if it does not. We can test this behavior using the GIT_TEST_MAINT_SCHEDULER environment variable. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24t9001: PATH must not use Windows-style pathsLibravatar Johannes Sixt1-1/+1
On Windows, $(pwd) returns a drive-letter style path C:/foo, while $PWD contains a POSIX style /c/foo path. When we want to interpolate the current directory in the PATH variable, we must not use the C:/foo style, because the meaning of the colon is ambiguous. Use the POSIX style. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24t5582: remove spurious 'cd "$D"' lineLibravatar Mickey Endito1-1/+0
The variable D is never defined in test t5582, more severely the test fails if D is defined by something outside the test suite, so remove this spurious line. Signed-off-by: Mickey Endito <mickey.endito.2323@protonmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-23rebase -r: fix merge -c with a merge strategyLibravatar Phillip Wood1-0/+18
If a rebase is started with a --strategy option other than "ort" or "recursive" then "merge -c" does not allow the user to reword the commit message. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>