summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2013-11-01Merge branch 'jk/for-each-ref-skip-parsing'Libravatar Junio C Hamano1-0/+4
* jk/for-each-ref-skip-parsing: for-each-ref: avoid loading objects to print %(objectname)
2013-11-01Merge branch 'jl/submodule-mv'Libravatar Junio C Hamano1-0/+26
Moving a regular file in a repository with a .gitmodules file was producing a warning 'Could not find section in .gitmodules where path=<filename>'. * jl/submodule-mv: mv: Fix spurious warning when moving a file in presence of submodules
2013-10-30Merge branch 'tr/valgrind-test-fix'Libravatar Junio C Hamano1-99/+34
* tr/valgrind-test-fix: Revert "test-lib: allow prefixing a custom string before "ok N" etc." Revert "test-lib: support running tests under valgrind in parallel"
2013-10-30Merge branch 'nd/magic-pathspec'Libravatar Junio C Hamano1-0/+15
All callers to parse_pathspec() must choose between getting no pathspec or one path that is limited to the current directory when there is no paths given on the command line, but there were two callers that violated this rule, triggering a BUG(). * nd/magic-pathspec: Fix calling parse_pathspec with no paths nor PATHSPEC_PREFER_* flags
2013-10-30Merge branch 'nd/gc-lock-against-each-other'Libravatar Junio C Hamano1-0/+5
* nd/gc-lock-against-each-other: gc: remove gc.pid file at end of execution
2013-10-30Merge branch 'mm/checkout-auto-track-fix'Libravatar Junio C Hamano2-0/+27
"git checkout topic", when there is not yet a local "topic" branch but there is a unique remote-tracking branch for a remote "topic" branch, pretended as if "git checkout -t -b topic remote/$r/topic" (for that unique remote $r) was run. This hack however was not implemented for "git checkout topic --". * mm/checkout-auto-track-fix: checkout: proper error message on 'git checkout foo bar --' checkout: allow dwim for branch creation for "git checkout $branch --"
2013-10-30Merge branch 'sg/t3600-nul-sha1-fix'Libravatar Junio C Hamano1-7/+4
* sg/t3600-nul-sha1-fix: t3600: fix broken "choking git rm" test
2013-10-30Merge branch 'jc/upload-pack-send-symref'Libravatar Junio C Hamano3-14/+18
One long-standing flaw in the pack transfer protocol used by "git clone" was that there was no way to tell the other end which branch "HEAD" points at, and the receiving end needed to guess. A new capability has been defined in the pack protocol to convey this information so that cloning from a repository with more than one branches pointing at the same commit where the HEAD is at now reliably sets the initial branch in the resulting repository. * jc/upload-pack-send-symref: t5570: Update for clone-progress-to-stderr branch t5570: Update for symref capability clone: test the new HEAD detection logic connect: annotate refs with their symref information in get_remote_head() connect.c: make parse_feature_value() static upload-pack: send non-HEAD symbolic refs upload-pack: send symbolic ref information as capability upload-pack.c: do not pass confusing cb_data to mark_our_ref() t5505: fix "set-head --auto with ambiguous HEAD" test
2013-10-30Merge branch 'jk/http-auth-redirects'Libravatar Junio C Hamano3-1/+15
Handle the case where http transport gets redirected during the authorization request better. * jk/http-auth-redirects: http.c: Spell the null pointer as NULL remote-curl: rewrite base url from info/refs redirects remote-curl: store url as a strbuf remote-curl: make refs_url a strbuf http: update base URLs when we see redirects http: provide effective url to callers http: hoist credential request out of handle_curl_result http: refactor options to http_get_* http_request: factor out curlinfo_strbuf http_get_file: style fixes
2013-10-30for-each-ref: avoid loading objects to print %(objectname)Libravatar Jeff King1-0/+4
If you ask for-each-ref to print each ref and its object, like: git for-each-ref --format='%(objectname) %(refname)' this should involve little more work than looking at the ref files (and packed-refs) themselves. However, for-each-ref will actually load each object from disk just to print its sha1. For most repositories, this isn't a big deal, but it can be noticeable if you have a large number of refs to print. Here are best-of-five timings for the command above on a repo with ~10K refs: [before] real 0m0.112s user 0m0.092s sys 0m0.016s [after] real 0m0.014s user 0m0.012s sys 0m0.000s This patch checks for %(objectname) and %(objectname:short) before we actually parse the object (and the rest of the code is smart enough to avoid parsing if we have filled all of our placeholders). Note that we can't simply move the objectname parsing code into the early loop. If the "deref" form %(*objectname) is used, then we do need to parse the object in order to peel the tag. So instead of moving the code, we factor it out into a separate function that can be called for both cases. While we're at it, we add some basic tests for the dereferenced placeholders, which were not tested at all before. This helps ensure we didn't regress that case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-28Sync with v1.8.4.2Libravatar Junio C Hamano1-1/+1
2013-10-28Merge branch 'jk/split-broken-ident'Libravatar Junio C Hamano1-2/+7
Make the fall-back parsing of commit objects with broken author or committer lines more robust to pick up the timestamps. * jk/split-broken-ident: split_ident: parse timestamp from end of line
2013-10-28Merge branch 'jc/revision-range-unpeel'Libravatar Junio C Hamano1-0/+8
"git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the output, but "git rev-list --objects v1.0^..v1.0" did not. * jc/revision-range-unpeel: revision: do not peel tags used in range notation
2013-10-28Merge branch 'jx/relative-path-regression-fix'Libravatar Junio C Hamano1-28/+32
* jx/relative-path-regression-fix: Use simpler relative_path when set_git_dir relative_path should honor dos-drive-prefix test: use unambigous leading path (/foo) for MSYS
2013-10-28Merge branch 'jk/clone-progress-to-stderr' into maintLibravatar Junio C Hamano3-5/+11
"git clone" gave some progress messages to the standard output, not to the standard error, and did not allow suppressing them with the "--no-progress" option. * jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr
2013-10-28Merge branch 'jk/format-patch-from' into maintLibravatar Junio C Hamano1-0/+10
"format-patch --from=<whom>" forgot to omit unnecessary in-body from line, i.e. when <whom> is the same as the real author. * jk/format-patch-from: format-patch: print in-body "From" only when needed
2013-10-28Merge branch 'jk/shortlog-tolerate-broken-commit' into maintLibravatar Junio C Hamano1-0/+16
"git shortlog" used to choke and die when there is a malformed commit (e.g. missing authors); it now simply ignore such a commit and keeps going. * jk/shortlog-tolerate-broken-commit: shortlog: ignore commits with missing authors
2013-10-28test-lib: fix typo in commentLibravatar Torstein Hegge1-1/+1
Point test writers to the test_expect_* functions properly. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Merge branch 'jc/ls-files-killed-optim' into maintLibravatar Junio C Hamano1-8/+19
"git ls-files -k" needs to crawl only the part of the working tree that may overlap the paths in the index to find killed files, but shared code with the logic to find all the untracked files, which made it unnecessarily inefficient. * jc/ls-files-killed-optim: dir.c::test_one_path(): work around directory_exists_in_index_icase() breakage t3010: update to demonstrate "ls-files -k" optimization pitfalls ls-files -k: a directory only can be killed if the index has a non-directory dir.c: use the cache_* macro to access the current index
2013-10-23Merge branch 'jh/checkout-auto-tracking' into maintLibravatar Junio C Hamano2-4/+40
"git branch --track" had a minor regression in v1.8.3.2 and later that made it impossible to base your local work on anything but a local branch of the upstream repository you are tracking from. * jh/checkout-auto-tracking: t3200: fix failure on case-insensitive filesystems branch.c: Relax unnecessary requirement on upstream's remote ref name t3200: Add test demonstrating minor regression in 41c21f2 Refer to branch.<name>.remote/merge when documenting --track t3200: Minor fix when preparing for tracking failure t2024: Fix &&-chaining and a couple of typos
2013-10-23Merge branch 'nd/fetch-into-shallow' into maintLibravatar Junio C Hamano2-3/+11
When there is no sufficient overlap between old and new history during a "git fetch" into a shallow repository, objects that the sending side knows the receiving end has were unnecessarily sent. * nd/fetch-into-shallow: Add testcase for needless objects during a shallow fetch list-objects: mark more commits as edges in mark_edges_uninteresting list-objects: reduce one argument in mark_edges_uninteresting upload-pack: delegate rev walking in shallow fetch to pack-objects shallow: add setup_temporary_shallow() shallow: only add shallow graft points to new shallow file move setup_alternate_shallow and write_shallow_commits to shallow.c
2013-10-23Merge branch 'hu/cherry-pick-previous-branch'Libravatar Junio C Hamano1-0/+12
"git cherry-pick" without further options would segfault. Could use a follow-up to handle '-' after argv[1] better. * hu/cherry-pick-previous-branch: cherry-pick: handle "-" after parsing options
2013-10-23Merge branch 'mg/more-textconv'Libravatar Junio C Hamano3-15/+60
Make "git grep" and "git show" pay attention to --textconv when dealing with blob objects. * mg/more-textconv: grep: honor --textconv for the case rev:path grep: allow to use textconv filters t7008: demonstrate behavior of grep with textconv cat-file: do not die on --textconv without textconv filters show: honor --textconv for blobs diff_opt: track whether flags have been set explicitly t4030: demonstrate behavior of show with textconv
2013-10-22Revert "test-lib: allow prefixing a custom string before "ok N" etc."Libravatar Thomas Rast1-15/+12
Now that ad0e623 (test-lib: support running tests under valgrind in parallel, 2013-06-23) has been reverted, this support code has no users any more. Revert it, too. This reverts commit e939e15d241e942662b9f88f6127ab470ab0a0b9. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Revert "test-lib: support running tests under valgrind in parallel"Libravatar Thomas Rast1-84/+22
This reverts commit ad0e6233320b004f0d686f6887c803e508607bd2. --valgrind-parallel was broken from the start: during review I made the whole valgrind setup code conditional on not being a --valgrind-parallel worker child. But even the children crucially need $GIT_VALGRIND to be set; it should therefore have been set outside the conditional. The fix would be a two-liner, but since the introduction of the feature, almost four months have passed without anyone noticing that it is broken. So this feature is not worth the about hundred lines of test-lib.sh complexity. Revert it. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22t5570: Update for clone-progress-to-stderr branchLibravatar Brian Gernhardt1-2/+1
git clone now reports its progress to standard error, which throws off t5570. Using test_i18ngrep instead of test_cmp allows the test to be more flexible by only looking for the expected error and ignoring any other output from the program. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Merge branch 'jk/clone-progress-to-stderr' into jc/upload-pack-send-symrefLibravatar Junio C Hamano3-5/+11
* jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr
2013-10-22t5570: Update for symref capabilityLibravatar Brian Gernhardt1-1/+1
git-daemon now uses the symref capability to send the correct HEAD reference, so the test for that in t5570 now passes. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Fix calling parse_pathspec with no paths nor PATHSPEC_PREFER_* flagsLibravatar Nguyễn Thái Ngọc Duy1-0/+15
When parse_pathspec() is called with no paths, the behavior could be either return no paths, or return one path that is cwd. Some commands do the former, some the latter. parse_pathspec() itself does not make either the default and requires the caller to specify either flag if it may run into this situation. I've grep'd through all parse_pathspec() call sites. Some pass neither, but those are guaranteed never pass empty path to parse_pathspec(). There are two call sites that may pass empty path and are fixed with this patch. [jc: added a test from Antoine's bug report] Reported-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18Merge branch 'jk/clone-progress-to-stderr'Libravatar Junio C Hamano3-5/+11
Some progress and diagnostic messages from "git clone" were incorrectly sent to the standard output stream, not to the standard error stream. * jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr
2013-10-18checkout: proper error message on 'git checkout foo bar --'Libravatar Matthieu Moy1-0/+6
The previous code was detecting the presence of "--" by looking only at argument 1. As a result, "git checkout foo bar --" was interpreted as an ambiguous file/revision list, and errored out with: error: pathspec 'foo' did not match any file(s) known to git. error: pathspec 'bar' did not match any file(s) known to git. error: pathspec '--' did not match any file(s) known to git. This patch fixes it by walking through the argument list to find the "--", and now complains about the number of references given. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18checkout: allow dwim for branch creation for "git checkout $branch --"Libravatar Matthieu Moy1-0/+21
The "--" notation disambiguates files and branches, but as a side-effect of the previous implementation, also disabled the branch auto-creation when $branch does not exist. A possible scenario is then: git checkout $branch => fails if $branch is both a ref and a file, and suggests -- git checkout $branch -- => refuses to create the $branch This patch allows the second form to create $branch, and since the -- is provided, it does not look for file named $branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18gc: remove gc.pid file at end of executionLibravatar Jonathan Nieder1-0/+5
This file isn't really harmful, but isn't useful either, and can create minor annoyance for the user: * It's confusing, as the presence of a *.pid file often implies that a process is currently running. A user running "ls .git/" and finding this file may incorrectly guess that a "git gc" is currently running. * Leaving this file means that a "git gc" in an already gc-ed repo is no-longer a no-op. A user running "git gc" in a set of repositories, and then synchronizing this set (e.g. rsync -av, unison, ...) will see all the gc.pid files as changed, which creates useless noise. This patch unlinks the file after the garbage collection is done, so that gc.pid is actually present only during execution. Future versions of Git may want to use the information left in the gc.pid file (e.g. for policies like "don't attempt to run a gc if one has already been ran less than X hours ago"). If so, this patch can safely be reverted. For now, let's not bother the users. Explained-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Merge branch 'jk/format-patch-from'Libravatar Junio C Hamano1-0/+10
"format-patch --from=<whom>" forgot to omit unnecessary in-body from line, i.e. when <whom> is the same as the real author. * jk/format-patch-from: format-patch: print in-body "From" only when needed
2013-10-17Merge branch 'jk/trailing-slash-in-pathspec'Libravatar Junio C Hamano1-2/+4
Code refactoring. * jk/trailing-slash-in-pathspec: reset: handle submodule with trailing slash rm: re-use parse_pathspec's trailing-slash removal
2013-10-17Sync with maintLibravatar Junio C Hamano1-21/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Merge branch 'nd/git-dir-pointing-at-gitfile' into maintLibravatar Junio C Hamano1-0/+4
* nd/git-dir-pointing-at-gitfile: Make setup_git_env() resolve .git file when $GIT_DIR is not specified
2013-10-17Merge branch 'ap/commit-author-mailmap' into maintLibravatar Junio C Hamano1-0/+11
* ap/commit-author-mailmap: commit: search author pattern against mailmap
2013-10-17Merge branch 'es/rebase-i-no-abbrev' into maintLibravatar Junio C Hamano1-2/+87
* es/rebase-i-no-abbrev: rebase -i: fix short SHA-1 collision t3404: rebase -i: demonstrate short SHA-1 collision t3404: make tests more self-contained Conflicts: t/t3404-rebase-interactive.sh
2013-10-17Merge branch 'rt/rebase-p-no-merge-summary' into maintLibravatar Junio C Hamano1-0/+23
* rt/rebase-p-no-merge-summary: rebase --preserve-merges: ignore "merge.log" config
2013-10-17t4254: modernize testsLibravatar SZEDER Gábor1-21/+15
- Don't start tests with 'test $? = 0' to catch preparation done outside the test_expect_success block. - Move writing the bogus patch and the expected output into the appropriate test_expect_success blocks. - Use the test_must_fail helper instead of manually checking for non-zero exit code. - Use the debug-friendly test_path_is_file helper instead of 'test -f'. - No space after '>'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-16t3600: fix broken "choking git rm" testLibravatar SZEDER Gábor1-7/+4
The test 'choking "git rm" should not let it die with cruft' is supposed to check 'git rm's behavior when interrupted by provoking a SIGPIPE while 'git rm' is busily deleting files from a specially crafted index. This test is silently broken for the following reasons: - The test crafts a special index by feeding a large number of index entries with null shas to 'git update-index --index-info'. It was OK back then when this test was introduced in commit 0693f9ddad (Make sure lockfiles are unlocked when dying on SIGPIPE, 2008-12-18), but since commit 4337b5856f (do not write null sha1s to on-disk index, 2012-07-28) null shas are not allowed in the on-disk index causing 'git update-index' to error out. - The barfing 'git update-index --index-info' should fail the test, but it remains unnoticed because of the severely broken && chain: the test's result depends solely on whether there is a stale lock file left behind, but after 'git update-index' errors out 'git rm' won't be executed at all. To fix this test feed only non-null shas to 'git update-index' and restore the && chain (partly by adding a missing && and by using the test_when_finished helper instead of manual cleanup). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-16Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano1-0/+67
* git://git.bogomips.org/git-svn: git-svn: Warn about changing default for --prefix in Git v2.0 Documentation/git-svn: Promote the use of --prefix in docs + examples git-svn.txt: elaborate on rev_map files git-svn.txt: replace .git with $GIT_DIR git-svn.txt: reword description of gc command git-svn.txt: fix AsciiDoc formatting error git-svn: fix signed commit parsing
2013-10-15revision: do not peel tags used in range notationLibravatar Junio C Hamano1-0/+8
A range notation "A..B" means exactly the same thing as what "^A B" means, i.e. the set of commits that are reachable from B but not from A. But the internal representation after the revision parser parsed these two notations are subtly different. - "rev-list ^A B" leaves A and B in the revs->pending.objects[] array, with the former marked as UNINTERESTING and the revision traversal machinery propagates the mark to underlying commit objects A^0 and B^0. - "rev-list A..B" peels tags and leaves A^0 (marked as UNINTERESTING) and B^0 in revs->pending.objects[] array before the traversal machinery kicks in. This difference usually does not matter, but starts to matter when the --objects option is used. For example, we see this: $ git rev-list --objects v1.8.4^1..v1.8.4 | grep $(git rev-parse v1.8.4) $ git rev-list --objects v1.8.4 ^v1.8.4^1 | grep $(git rev-parse v1.8.4) 04f013dc38d7512eadb915eba22efc414f18b869 v1.8.4 With the former invocation, the revision traversal machinery never hears about the tag v1.8.4 (it only sees the result of peeling it, i.e. the commit v1.8.4^0), and the tag itself does not appear in the output. The latter does send the tag object itself to the output. Make the range notation keep the unpeeled objects and feed them to the traversal machinery to fix this inconsistency. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-15Merge branch 'maint'Libravatar Junio C Hamano1-1/+7
* maint: git-prune-packed.txt: fix reference to GIT_OBJECT_DIRECTORY clone --branch: refuse to clone if upstream repo is empty
2013-10-15split_ident: parse timestamp from end of lineLibravatar Jeff King1-2/+7
Split_ident currently parses left to right. Given this input: Your Name <email@example.com> 123456789 -0500\n We assume the name starts the line and runs until the first "<". That starts the email address, which runs until the first ">". Everything after that is assumed to be the timestamp. This works fine in the normal case, but is easily broken by corrupted ident lines that contain an extra ">". Some examples seen in the wild are: 1. Name <email>-<> 123456789 -0500\n 2. Name <email> <Name<email>> 123456789 -0500\n 3. Name1 <email1>, Name2 <email2> 123456789 -0500\n Currently each of these produces some email address (which is not necessarily the one the user intended) and end up with a NULL date (which is generally interpreted as the epoch by "git log" and friends). But in each case we could get the correct timestamp simply by parsing from the right-hand side, looking backwards for the final ">", and then reading the timestamp from there. In general, it's a losing battle to try to automatically guess what the user meant with their broken crud. But this particular workaround is probably worth doing. One, it's dirt simple, and can't impact non-broken cases. Two, it doesn't catch a single breakage we've seen, but rather a large class of errors (i.e., any breakage inside the email angle brackets may affect the email, but won't spill over into the timestamp parsing). And three, the timestamp is arguably more valuable to get right, because it can affect correctness (e.g., in --until cutoffs). This patch implements the right-to-left scheme described above. We adjust the tests in t4212, which generate a commit with such a broken ident, and now gets the timestamp right. We also add a test that fsck continues to detect the breakage. For reference, here are pointers to the breakages seen (as numbered above): [1] http://article.gmane.org/gmane.comp.version-control.git/221441 [2] http://article.gmane.org/gmane.comp.version-control.git/222362 [3] http://perl5.git.perl.org/perl.git/commit/13b79730adea97e660de84bbe67f9d7cbe344302 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-14remote-curl: rewrite base url from info/refs redirectsLibravatar Jeff King3-1/+15
For efficiency and security reasons, an earlier commit in this series taught http_get_* to re-write the base url based on redirections we saw while making a specific request. This commit wires that option into the info/refs request, meaning that a redirect from http://example.com/foo.git/info/refs to https://example.com/bar.git/info/refs will behave as if "https://example.com/bar.git" had been provided to git in the first place. The tests bear some explanation. We introduce two new hierearchies into the httpd test config: 1. Requests to /smart-redir-limited will work only for the initial info/refs request, but not any subsequent requests. As a result, we can confirm whether the client is re-rooting its requests after the initial contact, since otherwise it will fail (it will ask for "repo.git/git-upload-pack", which is not redirected). 2. Requests to smart-redir-auth will redirect, and require auth after the redirection. Since we are using the redirected base for further requests, we also update the credential struct, in order not to mislead the user (or credential helpers) about which credential is needed. We can therefore check the GIT_ASKPASS prompts to make sure we are prompting for the new location. Because we have neither multiple servers nor https support in our test setup, we can only redirect between paths, meaning we need to turn on credential.useHttpPath to see the difference. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-14Merge branch 'rj/highlight-test-hang'Libravatar Jonathan Nieder1-2/+4
* rj/highlight-test-hang: gitweb test: fix highlight test hang on Linux Mint
2013-10-14gitweb test: fix highlight test hang on Linux MintLibravatar Ramsay Jones1-2/+4
Linux Mint has an implementation of the highlight command (unrelated to the one from http://www.andre-simon.de) that works as a simple filter. The script uses 'sed' to add terminal colour escape codes around text matching a regular expression. When t9500-*.sh attempts to run "highlight --version", the script simply hangs waiting for input. (See https://bugs.launchpad.net/linuxmint/+bug/815005). The tool required by gitweb can be installed from the 'highlight' package. Unfortunately, given the default $PATH, this leads to the tool having lower precedence than the script. In order to avoid hanging the test, add '</dev/null' to the command line of the highlight invocation. Also, since the 'highlight' tool requred by gitweb produces '--version' output (and the script does not), saving the command output allows a simple check for the wrong 'highlight'. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-14clone --branch: refuse to clone if upstream repo is emptyLibravatar Ralf Thielow1-1/+7
Since 920b691 (clone: refuse to clone if --branch points to bogus ref) we refuse to clone with option "-b" if the specified branch does not exist in the (non-empty) upstream. If the upstream repository is empty, the branch doesn't exist, either. So refuse the clone too. Reported-by: Robert Mitwicki <robert.mitwicki@opensoftware.pl> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>