Граф коммитов

16 Коммитов

Автор SHA1 Сообщение Дата
Shawn O. Pearce 466dbc42f5 receive-pack: Send internal errors over side-band #2
If the client has requested side-band-64k capability, send any
of the internal error or warning messages in the muxed side-band
stream using the same band as our hook output, band #2.  By putting
everything in one stream we ensure all messages are processed by
the side-band demuxer, avoiding interleaving between our own stderr
and the side-band demuxer's stderr buffers.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-10 09:51:07 -08:00
Shawn O. Pearce 6b3fa7e7d1 t5401: Use a bare repository for the remote peer
We want to avoid the warnings (or later, test failures) about
updating the current branch.  It was never my intention to have
this test deal with a repository with a working directory, and it
is a very old bug that the test even used a non-bare repository
for the remote side of the push operations.

This fixes the interleaved output error we were seeing as a test
failure by avoiding the giant warning message we were getting back
about updating the current branch being risky.

Its not a real fix, but is something we should do no matter what,
because the behavior will change in the future to reject, and the
test would break at that time.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-09 19:25:36 -08:00
Shawn O. Pearce 6d525d389f receive-pack: Send hook output over side band #2
If the client requests to enable side-band-64k capability we can
safely send any hook stdout or stderr data down side band #2,
so the client can present it to the user.

If side-band-64k isn't enabled, hooks continue to inherit stderr
from the parent receive-pack process.

When the side band channel is being used the push client will wind up
prefixing all server messages with "remote: ", just like fetch does,
so our test vector has to be updated with the new expected output.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-05 20:57:27 -08:00
Nanako Shiraishi 3604e7c5c6 tests: use "git xyzzy" form (t3600 - t6999)
Converts tests between t3600-t6300.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 14:13:59 -07:00
Stephan Beyer d492b31caf t/: Use "test_must_fail git" instead of "! git"
This patch changes every occurrence of "! git" -- with the meaning
that a git call has to gracefully fail -- into "test_must_fail git".

This is useful to

 - make sure the test does not fail because of a signal,
   e.g. SIGSEGV, and

 - advertise the use of "test_must_fail" for new tests.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 13:21:26 -07:00
Junio C Hamano 3af828634f tests: do not use implicit "git diff --no-index"
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done.  We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".

Rather use test_cmp for that purpose.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 00:01:56 -07:00
Junio C Hamano 41ac414ea2 Sane use of test_expect_failure
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision.  Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:

    test_expect_{success,failure} 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        what is to be tested
    '

And expecting a failure exit from the whole sequence misses the
point of writing tests.  Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test.  The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.

This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:

    test_expect_success 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        ! this command should fail
    '

test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass.  So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:

    test_expect_failure 'git-foo should create bar' '
        rm -f bar &&
        git foo &&
        test -f bar
    '

This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 20:49:34 -08:00
Shawn O. Pearce 733f1815ab Use 'printf %s $x' notation in t5401
We only care about getting what should be an empty string and
sending it to a file, without a trailing LF, so the empty string
translates into a 0 byte file.  Earlier when I originally wrote
these lines Mac OS X allowed the format string of printf to be
the empty string, but more recent versions appear to have been
'improved' with error messages if the format is not given.

This may cause problems if we ever wind up with changes to the hook
tests.  A minor cleanup makes the test more safe on all systems,
by conforming to accepted printf conventions.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 17:17:39 -08:00
Junio C Hamano 0feb4d1c99 t/t{3600,3800,5401}: do not use egrep when grep would do
There is nothing _wrong_ with egrep per se, but this way we
would have less dependency on external tools.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-05 00:07:57 -08:00
Junio C Hamano 5be60078c9 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-02 22:52:14 -07:00
Shawn O. Pearce f43cd49fb8 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-11 22:56:03 -07:00
Junio C Hamano cf6981d493 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-10 23:26:33 -08:00
Shawn O. Pearce 05ef58ec1f 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 15:03:33 -08:00
Johannes Schindelin 5bd74506cd 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-03-04 00:24:15 -08:00
Jason Riedy 2aad957a51 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-15 22:23:21 -08:00
Shawn O. Pearce 27086d0f84 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 00:21:37 -08:00