aboutsummaryrefslogtreecommitdiff
path: root/t/t5702-clone-options.sh
Commit message (Collapse)AuthorAge
* clone: treat "checking connectivity" like other progressJeff King2013-09-18
| | | | | | | | | | | | | | | | | | | | | When stderr does not point to a tty, we typically suppress "we are now in this phase" progress reporting (e.g., we ask the server not to send us "counting objects" and the like). The new "checking connectivity" message is in the same vein, and should be suppressed. Since clone relies on the transport code to make the decision, we can simply sneak a peek at the "progress" field of the transport struct. That properly takes into account both the verbosity and progress options we were given, as well as the result of isatty(). Note that we do not set up that progress flag for a local clone, as we do not fetch using the transport at all. That's acceptable here, though, because we also do not perform a connectivity check in that case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* clone: send diagnostic messages to stderrJeff King2013-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | Putting messages like "Cloning into.." and "done" on stdout is un-Unix and uselessly clutters the stdout channel. Send them to stderr. We have to tweak two tests to accommodate this: 1. t5601 checks for doubled output due to forking, and doesn't actually care where the output goes; adjust it to check stderr. 2. t5702 is trying to test whether progress output was sent to stderr, but naively does so by checking whether stderr produced any output. Instead, have it look for "%", a token found in progress output but not elsewhere (and which lets us avoid hard-coding the progress text in the test). This should not regress any scripts that try to parse the current output, as the output is already internationalized and therefore unstable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* test: test_must_be_empty helperJunio C Hamano2013-06-09
| | | | | | | | | | | | | | | There are quite a lot places where an output file is expected to be empty, and we fail the test when it is not. The output from running the test script with -i -v can be helped if we showed the unexpected contents at that point. We could of course do >expected.empty && test_cmp expected.empty actual but this is commmon enough to be done with a dedicated helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* clone: use --progress to force progress reportingTay Ray Chuan2009-12-28
| | | | | | | | | | | | | | | Follow the argument convention of git-pack-objects, such that a separate option (--preogress) is used to force progress reporting instead of -v/--verbose. -v/--verbose now does not force progress reporting. Make git-clone.txt say so. This should cover all the bases in 21188b1 (Implement git clone -v), which implemented the option to force progress reporting. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Implement git clone -vMiklos Vajna2008-10-09
| | | | | | | | | | The new -v option forces the progressbar, even in case the output is not a terminal. This can be useful if the caller is an IDE or wrapper which wants to scrape the progressbar from stderr and show its information in a different format. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* test "git clone -o"Jeff King2007-12-19
This tests a recently fixed regression in which "git clone -o" didn't work at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>