mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 08:47:56 +01:00
Code Activity
git/t/t5401-update-hooks.sh

137 lines
3.6 KiB
Bash
Raw Normal View History

Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
#!/bin/sh
#
# Copyright (c) 2006 Shawn O. Pearce
#
test_description='Test the update hook infrastructure.'
. ./test-lib.sh
test_expect_success setup '
echo This is a test. >a &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git update-index --add a &&
tree0=$(git write-tree) &&
commit0=$(echo setup | git commit-tree $tree0) &&
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
echo We hope it works. >a &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git update-index a &&
tree1=$(git write-tree) &&
commit1=$(echo modify | git commit-tree $tree1 -p $commit0) &&
git update-ref refs/heads/master $commit0 &&
git update-ref refs/heads/tofail $commit1 &&
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
git-clone ./. victim &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
GIT_DIR=victim/.git git update-ref refs/heads/tofail $commit1 &&
git update-ref refs/heads/master $commit1 &&
git update-ref refs/heads/tofail $commit0
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
cat >victim/.git/hooks/pre-receive <<'EOF'
#!/bin/sh
Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10 09:28:16 +01:00
printf "$@" >>$GIT_DIR/pre-receive.args
cat - >$GIT_DIR/pre-receive.stdin
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
echo STDOUT pre-receive
echo STDERR pre-receive >&2
EOF
chmod u+x victim/.git/hooks/pre-receive
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
cat >victim/.git/hooks/update <<'EOF'
#!/bin/sh
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
echo "$@" >>$GIT_DIR/update.args
Replace "echo -n" with printf in shell scripts. Not all echos know -n. This was causing a test failure in t5401-update-hooks.sh, but not t3800-mktag.sh for some reason. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 02:31:29 +01:00
read x; printf "$x" >$GIT_DIR/update.stdin
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
echo STDOUT update $1
echo STDERR update $1 >&2
test "$1" = refs/heads/master || exit
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
EOF
chmod u+x victim/.git/hooks/update
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
cat >victim/.git/hooks/post-receive <<'EOF'
#!/bin/sh
Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10 09:28:16 +01:00
printf "$@" >>$GIT_DIR/post-receive.args
cat - >$GIT_DIR/post-receive.stdin
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
echo STDOUT post-receive
echo STDERR post-receive >&2
EOF
chmod u+x victim/.git/hooks/post-receive
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
cat >victim/.git/hooks/post-update <<'EOF'
#!/bin/sh
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
echo "$@" >>$GIT_DIR/post-update.args
Replace "echo -n" with printf in shell scripts. Not all echos know -n. This was causing a test failure in t5401-update-hooks.sh, but not t3800-mktag.sh for some reason. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 02:31:29 +01:00
read x; printf "$x" >$GIT_DIR/post-update.stdin
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
echo STDOUT post-update
echo STDERR post-update >&2
EOF
chmod u+x victim/.git/hooks/post-update
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
test_expect_failure push '
git-send-pack --force ./victim/.git master tofail >send.out 2>send.err
'
test_expect_success 'updated as expected' '
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
test $(GIT_DIR=victim/.git git rev-parse master) = $commit1 &&
test $(GIT_DIR=victim/.git git rev-parse tofail) = $commit1
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
test_expect_success 'hooks ran' '
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
test -f victim/.git/pre-receive.args &&
test -f victim/.git/pre-receive.stdin &&
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
test -f victim/.git/update.args &&
test -f victim/.git/update.stdin &&
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
test -f victim/.git/post-receive.args &&
test -f victim/.git/post-receive.stdin &&
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
test -f victim/.git/post-update.args &&
test -f victim/.git/post-update.stdin
'
Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10 09:28:16 +01:00
test_expect_success 'pre-receive hook input' '
(echo $commit0 $commit1 refs/heads/master;
echo $commit1 $commit0 refs/heads/tofail
) | git diff - victim/.git/pre-receive.stdin
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
'
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
test_expect_success 'update hook arguments' '
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
(echo refs/heads/master $commit0 $commit1;
echo refs/heads/tofail $commit1 $commit0
Merge branch 'js/diff-ni' * js/diff-ni: Get rid of the dependency to GNU diff in the tests diff --no-index: support /dev/null as filename diff-ni: fix the diff with standard input diff: support reading a file from stdin via "-"
2007-03-11 08:26:33 +01:00
) | git diff - victim/.git/update.args
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
'
Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10 09:28:16 +01:00
test_expect_success 'post-receive hook input' '
echo $commit0 $commit1 refs/heads/master |
git diff - victim/.git/post-receive.stdin
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
test_expect_success 'post-update hook arguments' '
echo refs/heads/master |
Get rid of the dependency to GNU diff in the tests Now that "git diff" handles stdin and relative paths outside the working tree correctly, we can convert all instances of "diff -u" to "git diff". This commit is really the result of $ perl -pi.bak -e 's/diff -u/git diff/' $(git grep -l "diff -u" t/) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from commit c699a40d68215c7e44a5b26117a35c8a56fbd387)
2007-02-25 23:36:53 +01:00
git diff - victim/.git/post-update.args
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
test_expect_success 'all hook stdin is /dev/null' '
! test -s victim/.git/update.stdin &&
! test -s victim/.git/post-update.stdin
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
Change {pre,post}-receive hooks to use stdin Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it is possible for a single invocation of receive-pack to be given more refs than the OS might allow us to pass as command line parameters to a single hook invocation. We don't want to break these up into multiple invocations (like xargs might do) as that makes it impossible for the pre-receive hook to verify multiple related ref updates occur at the same time, and it makes it harder for post-receive to send out a single batch notification. Instead we pass the reference data on a pipe connected to the hook's stdin, supplying one ref per line to the hook. This way a single hook invocation can obtain an infinite amount of ref data, without bumping into any operating system limits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10 09:28:16 +01:00
test_expect_success 'all *-receive hook args are empty' '
! test -s victim/.git/pre-receive.args &&
! test -s victim/.git/post-receive.args
'
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
test_expect_failure 'send-pack produced no output' '
test -s send.out
'
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
cat <<EOF >expect
STDOUT pre-receive
STDERR pre-receive
STDOUT update refs/heads/master
STDERR update refs/heads/master
STDOUT update refs/heads/tofail
STDERR update refs/heads/tofail
STDOUT post-receive
STDERR post-receive
STDOUT post-update
STDERR post-update
EOF
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
test_expect_success 'send-pack stderr contains hook messages' '
Teach receive-pack to run pre-receive/post-receive hooks Bill Lear pointed out that it is easy to send out notifications of changes with the update hook, but successful execution of the update hook does not necessarily mean that the ref was actually updated. Lock contention on the ref or being unable to append to the reflog may prevent the ref from being changed. Sending out notifications prior to the ref actually changing is very misleading. To help this situation I am introducing two new hooks to the receive-pack flow: pre-receive and post-receive. These new hooks are invoked only once per receive-pack execution and are passed three arguments per ref (refname, old-sha1, new-sha1). The new post-receive hook is ideal for sending out notifications, as it has the complete list of all refnames that were successfully updated as well as the old and new SHA-1 values. This allows more interesting notifications to be sent. Multiple ref updates could be easily summarized into one email, for example. The new pre-receive hook is ideal for logging update attempts, as it is run only once for the entire receive-pack operation. It can also be used to verify multiple updates happen at once, e.g. an update to the `maint` head must also be accompained by a new annotated tag. Lots of documentation improvements for receive-pack are included in this change, as we want to make sure the new hooks are clearly explained. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 22:52:05 +01:00
egrep ^STD send.err >actual &&
Merge branch 'js/diff-ni' * js/diff-ni: Get rid of the dependency to GNU diff in the tests diff --no-index: support /dev/null as filename diff-ni: fix the diff with standard input diff: support reading a file from stdin via "-"
2007-03-11 08:26:33 +01:00
git diff - actual <expect
Add test case for update hooks in receive-pack. Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31 08:20:23 +01:00
'
test_done
Copy permalink