2007-11-12 21:38:23 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='tracking branch update checks for git push'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
echo 1 >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m 1 &&
|
|
|
|
git branch b1 &&
|
|
|
|
git branch b2 &&
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
git branch b3 &&
|
2007-11-12 21:38:23 +00:00
|
|
|
git clone . aa &&
|
|
|
|
git checkout b1 &&
|
|
|
|
echo b1 >>file &&
|
|
|
|
git commit -a -m b1 &&
|
|
|
|
git checkout b2 &&
|
|
|
|
echo b2 >>file &&
|
|
|
|
git commit -a -m b2
|
|
|
|
'
|
|
|
|
|
2007-11-17 12:54:27 +00:00
|
|
|
test_expect_success 'prepare pushable branches' '
|
2007-11-12 21:38:23 +00:00
|
|
|
cd aa &&
|
|
|
|
b1=$(git rev-parse origin/b1) &&
|
|
|
|
b2=$(git rev-parse origin/b2) &&
|
|
|
|
git checkout -b b1 origin/b1 &&
|
|
|
|
echo aa-b1 >>file &&
|
|
|
|
git commit -a -m aa-b1 &&
|
|
|
|
git checkout -b b2 origin/b2 &&
|
|
|
|
echo aa-b2 >>file &&
|
|
|
|
git commit -a -m aa-b2 &&
|
|
|
|
git checkout master &&
|
|
|
|
echo aa-master >>file &&
|
2007-11-17 12:54:27 +00:00
|
|
|
git commit -a -m aa-master
|
|
|
|
'
|
|
|
|
|
2008-07-12 15:47:52 +00:00
|
|
|
test_expect_success 'mixed-success push returns error' '
|
2013-01-05 00:04:22 +00:00
|
|
|
test_must_fail git push origin :
|
2008-07-12 15:47:52 +00:00
|
|
|
'
|
2007-11-17 12:54:27 +00:00
|
|
|
|
|
|
|
test_expect_success 'check tracking branches updated correctly after push' '
|
|
|
|
test "$(git rev-parse origin/master)" = "$(git rev-parse master)"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'check tracking branches not updated for failed refs' '
|
2007-11-12 21:38:23 +00:00
|
|
|
test "$(git rev-parse origin/b1)" = "$b1" &&
|
|
|
|
test "$(git rev-parse origin/b2)" = "$b2"
|
|
|
|
'
|
|
|
|
|
2007-11-17 12:55:15 +00:00
|
|
|
test_expect_success 'deleted branches have their tracking branches removed' '
|
|
|
|
git push origin :b1 &&
|
|
|
|
test "$(git rev-parse origin/b1)" = "origin/b1"
|
|
|
|
'
|
|
|
|
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
test_expect_success 'already deleted tracking branches ignored' '
|
|
|
|
git branch -d -r origin/b3 &&
|
|
|
|
git push origin :b3 >output 2>&1 &&
|
t5404: relax overzealous test
In 0b294c0abf0 (make deleting a missing ref more quiet, 2008-07-08), we
added a test to verify that deleting an already-deleted ref does not
show an error.
Our test simply looks for the substring 'error' in the output of the
`git push`, which might look innocuous on the face of it.
Suppose, however, that you are a big fan of whales. Or even better: your
IT administrator has a whale of a time picking cute user names, e.g.
referring to you (due to your like of India Pale Ales) as "one of the
cuter rorquals" (see https://en.wikipedia.org/wiki/Rorqual to learn a
thing or two about rorquals) and hence your home directory becomes
/home/cuterrorqual. If you now run t5404, it fails! Why? Because the
test calls `git push origin :b3` which outputs:
To /home/cuterrorqual/git/t/trash directory.t5404-tracking-branches/.
- [deleted] b3
Note how there is no error displayed in that output? But of course
"error" is a substring of "cuterrorqual". And so that `grep error
output` finds something.
This bug was not, actually, caught having "error" as a substring of the
user name but while working in a worktree called "colorize-push-errors",
whose name was part of that output, too, suggesting that not even
testing for the *word* `error` via `git grep -w error output` would fix
the underlying issue.
This patch chooses instead to look for the prefix "error:" at the
beginning of the line, so that there can be no ambiguity that any catch
was indeed a message generated by Git's `error_builtin()` function.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 19:31:22 +00:00
|
|
|
! grep "^error: " output
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
'
|
|
|
|
|
2007-11-12 21:38:23 +00:00
|
|
|
test_done
|