2014-11-30 08:24:48 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='prune $GIT_DIR/worktrees'
|
|
|
|
|
|
2020-11-18 23:44:22 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2023-02-06 23:07:43 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2014-11-30 08:24:48 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
2015-03-30 20:47:47 +00:00
|
|
|
test_expect_success initialize '
|
|
|
|
|
git commit --allow-empty -m init
|
|
|
|
|
'
|
|
|
|
|
|
2015-06-29 12:51:18 +00:00
|
|
|
test_expect_success 'worktree prune on normal repo' '
|
|
|
|
|
git worktree prune &&
|
|
|
|
|
test_must_fail git worktree prune abc
|
2014-11-30 08:24:48 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'prune files inside $GIT_DIR/worktrees' '
|
|
|
|
|
mkdir .git/worktrees &&
|
|
|
|
|
: >.git/worktrees/abc &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
cat >expect <<EOF &&
|
|
|
|
|
Removing worktrees/abc: not a valid directory
|
|
|
|
|
EOF
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
! test -f .git/worktrees/abc &&
|
|
|
|
|
! test -d .git/worktrees
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'prune directories without gitdir' '
|
|
|
|
|
mkdir -p .git/worktrees/def/abc &&
|
|
|
|
|
: >.git/worktrees/def/def &&
|
|
|
|
|
cat >expect <<EOF &&
|
|
|
|
|
Removing worktrees/def: gitdir file does not exist
|
|
|
|
|
EOF
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
! test -d .git/worktrees/def &&
|
|
|
|
|
! test -d .git/worktrees
|
|
|
|
|
'
|
|
|
|
|
|
2015-01-27 15:38:49 +00:00
|
|
|
test_expect_success SANITY 'prune directories with unreadable gitdir' '
|
2014-11-30 08:24:48 +00:00
|
|
|
mkdir -p .git/worktrees/def/abc &&
|
|
|
|
|
: >.git/worktrees/def/def &&
|
|
|
|
|
: >.git/worktrees/def/gitdir &&
|
|
|
|
|
chmod u-r .git/worktrees/def/gitdir &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
test_i18ngrep "Removing worktrees/def: unable to read gitdir file" actual &&
|
|
|
|
|
! test -d .git/worktrees/def &&
|
|
|
|
|
! test -d .git/worktrees
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'prune directories with invalid gitdir' '
|
|
|
|
|
mkdir -p .git/worktrees/def/abc &&
|
|
|
|
|
: >.git/worktrees/def/def &&
|
|
|
|
|
: >.git/worktrees/def/gitdir &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
test_i18ngrep "Removing worktrees/def: invalid gitdir file" actual &&
|
|
|
|
|
! test -d .git/worktrees/def &&
|
|
|
|
|
! test -d .git/worktrees
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'prune directories with gitdir pointing to nowhere' '
|
|
|
|
|
mkdir -p .git/worktrees/def/abc &&
|
|
|
|
|
: >.git/worktrees/def/def &&
|
|
|
|
|
echo "$(pwd)"/nowhere >.git/worktrees/def/gitdir &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2014-11-30 08:24:48 +00:00
|
|
|
test_i18ngrep "Removing worktrees/def: gitdir file points to non-existent location" actual &&
|
|
|
|
|
! test -d .git/worktrees/def &&
|
|
|
|
|
! test -d .git/worktrees
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'not prune locked checkout' '
|
2015-03-20 17:44:12 +00:00
|
|
|
test_when_finished rm -r .git/worktrees &&
|
2014-11-30 08:24:48 +00:00
|
|
|
mkdir -p .git/worktrees/ghi &&
|
|
|
|
|
: >.git/worktrees/ghi/locked &&
|
2015-06-29 12:51:18 +00:00
|
|
|
git worktree prune &&
|
2014-11-30 08:24:48 +00:00
|
|
|
test -d .git/worktrees/ghi
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'not prune recent checkouts' '
|
2015-03-20 17:44:12 +00:00
|
|
|
test_when_finished rm -r .git/worktrees &&
|
2018-03-15 16:44:12 +00:00
|
|
|
git worktree add jlm HEAD &&
|
|
|
|
|
test -d .git/worktrees/jlm &&
|
|
|
|
|
rm -rf jlm &&
|
2015-06-29 12:51:18 +00:00
|
|
|
git worktree prune --verbose --expire=2.days.ago &&
|
2014-11-30 08:24:48 +00:00
|
|
|
test -d .git/worktrees/jlm
|
|
|
|
|
'
|
|
|
|
|
|
2015-03-30 20:47:47 +00:00
|
|
|
test_expect_success 'not prune proper checkouts' '
|
|
|
|
|
test_when_finished rm -r .git/worktrees &&
|
2020-11-18 23:44:22 +00:00
|
|
|
git worktree add --detach "$PWD/nop" main &&
|
2015-06-29 12:51:18 +00:00
|
|
|
git worktree prune &&
|
2015-03-30 20:47:47 +00:00
|
|
|
test -d .git/worktrees/nop
|
|
|
|
|
'
|
|
|
|
|
|
2020-06-10 06:30:46 +00:00
|
|
|
test_expect_success 'prune duplicate (linked/linked)' '
|
|
|
|
|
test_when_finished rm -fr .git/worktrees w1 w2 &&
|
|
|
|
|
git worktree add --detach w1 &&
|
|
|
|
|
git worktree add --detach w2 &&
|
|
|
|
|
sed "s/w2/w1/" .git/worktrees/w2/gitdir >.git/worktrees/w2/gitdir.new &&
|
|
|
|
|
mv .git/worktrees/w2/gitdir.new .git/worktrees/w2/gitdir &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git worktree prune --verbose 2>actual &&
|
2020-06-10 06:30:46 +00:00
|
|
|
test_i18ngrep "duplicate entry" actual &&
|
|
|
|
|
test -d .git/worktrees/w1 &&
|
|
|
|
|
! test -d .git/worktrees/w2
|
|
|
|
|
'
|
|
|
|
|
|
2020-06-10 06:30:47 +00:00
|
|
|
test_expect_success 'prune duplicate (main/linked)' '
|
|
|
|
|
test_when_finished rm -fr repo wt &&
|
|
|
|
|
test_create_repo repo &&
|
|
|
|
|
test_commit -C repo x &&
|
|
|
|
|
git -C repo worktree add --detach ../wt &&
|
|
|
|
|
rm -fr wt &&
|
|
|
|
|
mv repo wt &&
|
worktree: send "chatty" messages to stderr
The order in which the stdout and stderr streams are flushed is not
guaranteed to be the same across platforms or `libc` implementations.
This lack of determinism can lead to anomalous and potentially confusing
output if normal (stdout) output is flushed after error (stderr) output.
For instance, the following output which clearly indicates a failure due
to a fatal error:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
has been reported[1] on Microsoft Windows to appear as:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
which may confuse the reader into thinking that the command somehow
recovered and ran to completion despite the error.
This problem crops up because the "chatty" status message "Preparing
worktree" is sent to stdout, whereas the "fatal" error message is sent
to stderr. One way to fix this would be to flush stdout manually before
git-worktree reports any errors to stderr.
However, common practice in Git is for "chatty" messages to be sent to
stderr. Therefore, a more appropriate fix is to adjust git-worktree to
conform to that practice by sending its "chatty" messages to stderr
rather than stdout as is currently the case.
There may be concern that relocating messages from stdout to stderr
could break existing tooling, however, these messages are already
internationalized, thus are unstable. And, indeed, the "Preparing
worktree" message has already been the subject of somewhat significant
changes in 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24). Moreover, there is existing precedent, such as
68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which
likewise relocated "chatty" messages from stdout to stderr for
git-clone.
[1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/
Reported-by: Baruch Burstein <bmburstein@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 03:44:19 +00:00
|
|
|
git -C wt worktree prune --verbose 2>actual &&
|
2020-06-10 06:30:47 +00:00
|
|
|
test_i18ngrep "duplicate entry" actual &&
|
|
|
|
|
! test -d .git/worktrees/wt
|
|
|
|
|
'
|
|
|
|
|
|
2014-11-30 08:24:48 +00:00
|
|
|
test_done
|