summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
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-09-18clone: always set transport optionsLibravatar Jeff King1-0/+4
A clone will always create a transport struct, whether we are cloning locally or using an actual protocol. In the local case, we only use the transport to get the list of refs, and then transfer the objects out-of-band. However, there are many options that we do not bother setting up in the local case. For the most part, these are noops, because they only affect the object-fetching stage (e.g., the --depth option). However, some options do have a visible impact. For example, giving the path to upload-pack via "-u" does not currently work for a local clone, even though we need upload-pack to get the ref list. We can just drop the conditional entirely and set these options for both local and non-local clones. Rather than keep track of which options impact the object versus the ref fetching stage, we can simply let the noops be noops (and the cost of setting the options in the first place is not high). The one exception is that we also check that the transport provides both a "get_refs_list" and a "fetch" method. We will now be checking the former for both cases (which is good, since a transport that cannot fetch refs would not work for a local clone), and we tweak the conditional to check for a "fetch" only when we are non-local. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-18clone: treat "checking connectivity" like other progressLibravatar Jeff King1-1/+2
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>
2013-09-18clone: send diagnostic messages to stderrLibravatar Jeff King2-5/+6
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>
2013-09-17clone: test the new HEAD detection logicLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17connect: annotate refs with their symref information in get_remote_head()Libravatar Junio C Hamano1-11/+4
By doing this, clients of upload-pack can now reliably tell what ref a symbolic ref points at; the updated test in t5505 used to expect failure due to the ambiguity and made sure we give diagnostics, but we no longer need to be so pessimistic. Make sure we correctly learn which branch HEAD points at from the other side instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17t5505: fix "set-head --auto with ambiguous HEAD" testLibravatar Junio C Hamano1-0/+1
When two or more branches point at the same commit and HEAD is pointing at one of them, without the symref extension, there is no way to remotely tell which one of these branches HEAD points at. The test in question attempts to make sure that this situation is diagnosed and results in a failure. However, even if there _were_ a way to reliably tell which branch the HEAD points at, "set-head --auto" would fail if there is no remote tracking branch. Make sure that this test does not fail for that "wrong" reason. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-14Revert "Add new @ shortcut for HEAD"Libravatar Junio C Hamano1-2/+0
This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, as it does not just apply to "@" (and forms with modifiers like @{u} applied to it), but also affects e.g. "refs/heads/@/foo", which it shouldn't. The basic idea of giving a short-hand might be good, and the topic can be retried later, but let's revert to avoid affecting existing use cases for now for the upcoming release.
2013-08-14Revert "git stash: avoid data loss when "git stash save" kills a directory"Libravatar Junio C Hamano1-18/+0
This reverts commit a73653130edd6a8977106d45a8092c09040f9132, as it has been reported that "ls-files --killed" is too time-consuming in a deep directory with too many untracked crufts (e.g. $HOME/.git tracking only a few files). We'd need to revisit it later but "ls-files --killed" needs to be optimized before it happens.
2013-08-09Merge branch 'jk/submodule-subdirectory-ok'Libravatar Junio C Hamano1-1/+1
* jk/submodule-subdirectory-ok: t/t7407: fix two typos in submodule tests
2013-08-09t/t7407: fix two typos in submodule testsLibravatar Phil Hord1-1/+1
In t/t7407-submodule-foreach.sh there is a typo in one of the path names given for a test step. The correct path is nested1/nested2/.git, but nested1/nested1/nested2/.git is given instead. The typo is hidden because this line also accidentally omits the && chain operator. The omitted chain also means the return values of all the previous commands in this test are also being ignored. Fix the path and add the chain operator so the entire test sequence can be properly validated. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Merge branch 'es/blame-L-breakage'Libravatar Junio C Hamano1-2/+2
* es/blame-L-breakage: t8001, t8002: fix "blame -L :literal" test on NetBSD
2013-08-05t8001, t8002: fix "blame -L :literal" test on NetBSDLibravatar René Scharfe1-2/+2
Sub-test 42 of t8001 and t8002 ("blame -L :literal") fails on NetBSD with the following verbose output: git annotate -L:main hello.c Author F (expected 4, attributed 3) bad Author G (expected 1, attributed 1) good This is not caused by different behaviour of git blame or annotate on that platform, but by different test input, in turn caused by a sed command that forgets to add a newline on NetBSD. Here's the diff of the commit that adds "goodbye" to hello.c, for Linux: @@ -1,4 +1,5 @@ int main(int argc, const char *argv[]) { puts("hello"); + puts("goodbye"); } We see that it adds an extra TAB, but that's not a problem. Here's the same on NetBSD: @@ -1,4 +1,4 @@ int main(int argc, const char *argv[]) { puts("hello"); -} + puts("goodbye");} It also adds an extra TAB, but it is missing the newline character after the semicolon. The following patch gets rid of the extra TAB at the beginning, but more importantly adds the missing newline at the end in a (hopefully) portable way, mentioned in http://sed.sourceforge.net/sedfaq4.html. The diff becomes this, on both Linux and NetBSD: @@ -1,4 +1,5 @@ int main(int argc, const char *argv[]) { puts("hello"); + puts("goodbye"); } Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Merge branch 'dn/test-reject-utf-16'Libravatar Junio C Hamano2-2/+2
* dn/test-reject-utf-16: t3900: test rejecting log message with NULs correctly Add missing test file for UTF-16.
2013-08-05t3900: test rejecting log message with NULs correctlyLibravatar Junio C Hamano1-2/+2
It is not like that our longer term desire is to someday start accept log messages with NULs in them, so it is wrong to mark a test that demonstrates "git commit" that correctly fails given such an input as "expect-failure". "git commit" should fail today, and it should fail the same way in the future given a message with NUL in it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Add missing test file for UTF-16.Libravatar Brian M. Carlson1-0/+0
The test file that the UTF-16 rejection test looks for is missing, but this went unnoticed because the test is expected to fail anyway; as a consequence, the test fails because the file containing the commit message is missing, and not because the test file contains a NUL byte. Fix this by including a sample text file containing a commit message encoded in UTF-16. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Tested-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02Merge branch 'jk/cat-file-batch-optim'Libravatar Junio C Hamano1-7/+0
* jk/cat-file-batch-optim: Revert "cat-file: split --batch input lines on whitespace"
2013-08-02Revert "cat-file: split --batch input lines on whitespace"Libravatar Junio C Hamano1-7/+0
This reverts commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac; the update assumed that people only used the command to read from "rev-list --objects" output, whose lines begin with a 40-hex object name followed by a whitespace, but it turns out that scripts feed random extended SHA-1 expressions (e.g. "HEAD:$pathname") in which a whitespace has to be kept.
2013-08-01Merge branch 'ob/typofixes'Libravatar Junio C Hamano6-6/+6
* ob/typofixes: many small typofixes
2013-08-01Merge branch 'lf/echo-n-is-not-portable'Libravatar Junio C Hamano1-2/+2
* lf/echo-n-is-not-portable: Avoid using `echo -n` anywhere
2013-08-01Merge branch 'jx/clean-interactive'Libravatar Junio C Hamano1-2/+38
* jx/clean-interactive: git-clean: implement partial matching for selection Documentation/git-clean: fix description for range
2013-07-29many small typofixesLibravatar Ondřej Bílka6-6/+6
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Reviewed-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-29Avoid using `echo -n` anywhereLibravatar Lukas Fleischer1-2/+2
`echo -n` is non-portable. The POSIX specification says: Conforming applications that wish to do prompting without <newline> characters or that could possibly be expecting to echo a -n, should use the printf utility derived from the Ninth Edition system. Since all of the affected shell scripts use a POSIX shell shebang, replace `echo -n` invocations with printf. Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24Merge branch 'ml/avoid-using-grep-on-crlf-files'Libravatar Junio C Hamano3-2/+4
On systems that understand a CRLF as a line ending, tests in this script that worked on files with CRLF line endings using "grep" to extract matching lines may lose the CR at the end of lines that match, causing the actual output not to match the expected output. * ml/avoid-using-grep-on-crlf-files: test-lib.sh - define and use GREP_STRIPS_CR
2013-07-24Merge branch 'tr/line-log'Libravatar Junio C Hamano1-0/+13
Fix "log -L" command line parsing bugs. * tr/line-log: t4211: fix incorrect rebase at f8395edc (range-set: satisfy non-empty ranges invariant) line-log: fix "log -LN" crash when N is last line of file range-set: satisfy non-empty ranges invariant t4211: demonstrate crash when first -L encountered is empty range t4211: demonstrate empty -L range crash range-set: fix sort_and_merge_range_set() corner case bug
2013-07-24git-clean: implement partial matching for selectionLibravatar Jiang Xin1-2/+38
Document for interactive git-clean says: "You also could say `c` or `clean` above as long as the choice is unique". But it's not true, because only hotkey `c` and full match (`clean`) could work. Implement partial matching via find_unique function to make the document right. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24t4211: fix incorrect rebase at f8395edc (range-set: satisfy non-empty ranges ↵Libravatar Junio C Hamano1-1/+0
invariant) Wnen I rewrote "cat b.c | wc -l" into "wc -l <b.c" to squash in a suggestion on the list to this series, I screwed up subsequent rebase. Fix it up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23line-log: fix "log -LN" crash when N is last line of fileLibravatar Eric Sunshine1-1/+1
range-set invariants are: ranges must be (1) non-empty, (2) disjoint, (3) sorted in ascending order. line_log_data_insert() breaks the non-empty invariant under the following conditions: the incoming range is empty and the pathname attached to the range has not yet been encountered. In this case, line_log_data_insert() assigns the empty range to a new line_log_data record without taking any action to ensure that the empty range is eventually folded out. Subsequent range-set functions crash or throw an assertion failure upon encountering such an anomaly. Fix this bug. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23range-set: satisfy non-empty ranges invariantLibravatar Eric Sunshine1-1/+2
range-set invariants are: ranges must be (1) non-empty, (2) disjoint, (3) sorted in ascending order. During processing, various range-set utility functions break the invariants (for instance, by adding empty ranges), with the expectation that a finalizing sort_and_merge_range_set() will restore sanity. sort_and_merge_range_set(), however, neglects to fold out empty ranges, thus it fails to satisfy the non-empty constraint. Subsequent range-set functions crash or throw an assertion failure upon encountering such an anomaly. Rectify the situation by having sort_and_merge_range_set() fold out empty ranges. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23t4211: demonstrate crash when first -L encountered is empty rangeLibravatar Eric Sunshine1-0/+5
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23t4211: demonstrate empty -L range crashLibravatar Eric Sunshine1-0/+8
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23Merge branch 'mv/merge-ff-tristate'Libravatar Junio C Hamano1-1/+1
* mv/merge-ff-tristate: t7600: fix typo in test title
2013-07-23t7600: fix typo in test titleLibravatar Junio C Hamano1-1/+1
Spotted by Ram, confirmed by Miklos. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Sync with Git 1.8.3.4Libravatar Junio C Hamano1-1/+1
2013-07-22Merge branch 'jc/name-rev-exact-ref'Libravatar Junio C Hamano1-0/+24
Corrects the longstanding sloppiness in the implementation of name-rev that conflated "we take commit-ish" and "differences between tags and commits do not matter". * jc/name-rev-exact-ref: describe: fix --contains when a tag is given as input name-rev: differentiate between tags and commits they point at describe: use argv-array name-rev: allow converting the exact object name at the tip of a ref name-ref: factor out name shortening logic from name_ref()
2013-07-22Merge branch 'es/check-mailmap'Libravatar Junio C Hamano1-0/+43
A new command to allow scripts to query the mailmap information. * es/check-mailmap: t4203: test check-mailmap command invocation builtin: add git-check-mailmap command
2013-07-22Merge branch 'jx/clean-interactive'Libravatar Junio C Hamano2-18/+493
Add "interactive" mode to "git clean". The early part to refactor relative path related helper functions looked sensible. * jx/clean-interactive: test: run testcases with POSIX absolute paths on Windows test: add t7301 for git-clean--interactive git-clean: add documentation for interactive git-clean git-clean: add ask each interactive action git-clean: add select by numbers interactive action git-clean: add filter by pattern interactive action git-clean: use a git-add-interactive compatible UI git-clean: add colors to interactive git-clean git-clean: show items of del_list in columns git-clean: add support for -i/--interactive git-clean: refactor git-clean into two phases write_name{_quoted_relative,}(): remove redundant parameters quote_path_relative(): remove redundant parameter quote.c: substitute path_relative with relative_path path.c: refactor relative_path(), not only strip prefix test: add test cases for relative_path
2013-07-22Merge branch 'hv/config-from-blob'Libravatar Junio C Hamano1-0/+70
Allow configuration data to be read from in-tree blob objects, which would help working in a bare repository and submodule updates. * hv/config-from-blob: do not die when error in config parsing of buf occurs teach config --blob option to parse config from database config: make parsing stack struct independent from actual data source config: drop cf validity check in get_next_char() config: factor out config file stack management
2013-07-22Merge branch 'jk/t0008-sigpipe-fix'Libravatar Junio C Hamano1-2/+10
Fix for recent test breakage on 'master'. * jk/t0008-sigpipe-fix: t0008: avoid SIGPIPE race condition on fifo
2013-07-22Merge branch 'db/show-ref-head'Libravatar Junio C Hamano1-0/+167
The "--head" option to "git show-ref" was only to add "HEAD" to the list of candidate refs to be filtered by the usual rules (e.g. "--heads" that only show refs under refs/heads). Change the meaning of the option to always show "HEAD" regardless of what filtering will be applied to any other ref (this is a backward incompatible change, so I may need to add an entry to the Release Notes). * db/show-ref-head: show-ref: make --head always show the HEAD ref
2013-07-22Merge branch 'es/blame-L-breakage'Libravatar Junio C Hamano3-112/+269
The refactoring made for parsing "-L" option recently to support "git log -L" seems to have broken "git blame -L X,-5" to show 5 lines leading to X. * es/blame-L-breakage: blame-options.txt: explain that -L <start> and <end> are optional blame-options.txt: place each -L option variation on its own line t8001/t8002 (blame): add blame -L :funcname tests t8001/t8002 (blame): add blame -L tests t8001/t8002 (blame): modernize style line-range: fix "blame -L X,-N" regression
2013-07-22Merge branch 'mm/diff-no-patch-synonym-to-s'Libravatar Junio C Hamano1-9/+39
"git show -s" was less discoverable than it should be. * mm/diff-no-patch-synonym-to-s: Documentation/git-log.txt: capitalize section names Documentation: move description of -s, --no-patch to diff-options.txt Documentation/git-show.txt: include common diff options, like git-log.txt diff: allow --patch & cie to override -s/--no-patch diff: allow --no-patch as synonym for -s t4000-diff-format.sh: modernize style
2013-07-22Merge branch 'jc/mailmap-case-insensitivity'Libravatar Junio C Hamano1-0/+18
The mailmap mechanism unnecessarily downcased the e-mail addresses in the output, and also ignored the human name when it is a single character name. This now has become Eric Sunshine's series, even though it still is under jc/ hierarchy. * jc/mailmap-case-insensitivity: mailmap: style fixes mailmap: debug: avoid passing NULL to fprintf() '%s' conversion specification mailmap: debug: eliminate -Wformat field precision type warning mailmap: debug: fix malformed fprintf() format conversion specification mailmap: debug: fix out-of-order fprintf() arguments mailmap: do not downcase mailmap entries t4203: demonstrate loss of uppercase characters in canonical email mailmap: do not lose single-letter names t4203: demonstrate loss of single-character name in mailmap entry
2013-07-22Merge branch 'jc/simple-add-must-be-a-no-op'Libravatar Junio C Hamano1-0/+10
This detected a mismerge of one of "add-2.0" topics to the 'jch' and 'pu' branches. * jc/simple-add-must-be-a-no-op: t2202: make sure "git add" (no args) stays a no-op
2013-07-22update URL to the marc.info mail archiveLibravatar Ondřej Bílka1-1/+1
The name marc.theaimsgroup.com is no longer active, and has migrated to marc.info. Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-21Sync with maintLibravatar Junio C Hamano1-3/+20
* maint: Update draft release notes to 1.8.3.4 t9801: git-p4: check ignore files with client spec
2013-07-21Merge branch 'dk/maint-t5150-dirname' into maintLibravatar Junio C Hamano1-1/+1
* dk/maint-t5150-dirname: tests: allow sha1's as part of the path
2013-07-21Merge branch 'jc/maint-diff-core-safecrlf' into maintLibravatar Junio C Hamano1-0/+8
Avoid failing "git diff" when core.safecrlf is set to true, because the user cannot tell where the breakage is in preparation for fixing and committing. * jc/maint-diff-core-safecrlf: diff: demote core.safecrlf=true to core.safecrlf=warn