path: root/t/
AgeCommit message (Collapse)Author
2006-03-01Rip out merge-order and make "git log <paths>..." work again.Linus Torvalds
Well, assuming breaking --merge-order is fine, here's a patch (on top of the other ones) that makes git log <filename> actually work, as far as I can tell. I didn't add the logic for --before/--after flags, but that should be pretty trivial, and is independent of this anyway. Signed-off-by: Junio C Hamano <>
2005-12-28Fix skipping merge-order test with NO_OPENSSL=1.Gerrit Pape
Move git-rev-list --merge-order usage check for 'OpenSSL not linked' after test 1; we cannot trigger this unless we try to actually use --merge-order by giving some ref, and we do not have any ref until we run the first test to create commits. Signed-off-by: Gerrit Pape <> Signed-off-by: Junio C Hamano <>
2005-12-27Fix bogus tests on rev-list output.Junio C Hamano
These tests seem to mean checking the output with expected result, but was not doing its handrolled test helper function. Also fix the guard to workaround wc output that have whitespace padding, which was broken but not exposed because the test was not testing it ;-). Signed-off-by: Junio C Hamano <>
2005-10-11Use git-update-ref and git-symbolic-ref in testsJohannes Schindelin
This makes all tests pass on cygwin. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-09-08Big tool rename.Junio C Hamano
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <>
2005-07-30Skip --merge-order test when built with NO_OPENSSLJunio C Hamano
When built with NO_OPENSSL, rev-list --merge-order does not work, causing t6001 test to fail. Detect that and skip this test to allow continuing to the rest of the tests. Signed-off-by: Junio C Hamano <>
2005-07-07[PATCH] Prevent t6000 series from dropping useless sed.script in t/Junio C Hamano
The Makefile in the test suite directory considers any file matching t[0-9][0-9][0-9][0-9]-*.sh as the top-level test script to be executed. Unfortunately this was not documented, and the common test library, was named to match that pattern. This caused to be called from Makefile as the top-level program, causing it to leave t/sed.script file behind. Rename it to to prevent this, and document the naming convention a bit more clearly. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-07-07[PATCH] Write sed script directly into temp file, rather than a variableJon Seymour
When sed uses \n rather than ; as a separator (for BSD sed(1) compat), it is cleaner to use a file directly, rather than an environment variable containing \n characters. This change changes t/t6000 write to sed.script directly and changes the other tests to remove knowledge of sed.script. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-07-06[PATCH] Add a t/t6001 test case for a --merge-order bugJon Seymour
This test case demonstrates a problem with --merge-order. A | B |\ C D |/ E | F git-rev-list --merge-order A B doesn't produce the expected output of A B D C E F The problem is fixed by a subsequent patch. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-07-06[PATCH] Factor out useful test case infrastructure from t/t6001... into ↵Jon Seymour
t/ Functions that are useful to other t6xxx testcases are moved into To use these functions in a test case, use a test-case pre-amble like: . ./ . ../ # t6xxx specific functions Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-30[PATCH] Remove unnecessary sort from t6001 testcaseJon Seymour
This patch removes an unnecessary sort from the t6001 testcase. Sorts were previously necessary when testing non --merge-order cases because the output order wasn't entirely deterministic unless commit date was fixed. However, commit dates are now fixed, so the need for a sort has disappeared. So the sort has been removed. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-30[PATCH] Fix broken t6001 test caseJon Seymour
This fix fixes a t/t6001 test case break that was hidden by a bug in the test case infrastructure. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-30[PATCH] Demonstrate broken t6001 test case functionJon Seymour
Junio discovered a problem where an actual test case break was hidden because pipelines are not handled properly by the test infrastructure in t6001. This patch fixes the broken infrastructure (and demonstrates the break explicitly). A subsequent patch in this series will fix the test case so that it doesn't fail. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-30[PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]Jon Seymour
This patch makes --merge-order produce the same list as git-rev-list without --merge-order specified. In particular, if the graph looks like this: A | B |/ C | D The both git-rev-list B ^A and git-rev-list --merge-order will produce B. The unit tests have been changed to reflect the fact that the prune points are now formally part of the start list that is used to perform the --merge-order sort. That is: git-rev-list --merge-order A ^D used to produce = A | C It now produces: ^ A | C Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-30[PATCH] Test case that demonstrates problem with --merge-order ^ processingJon Seymour
Added a test case that shows that --merge-order doesn't produce the correct result in the following case. A | | B |/ C | D git-rev-list --merge-order A ^B should produce just A. Instead it produces BCD. A subsequent patch will fix this defect. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-23[PATCH] A test case that demonstrates a problem with merges with two roots.Jon Seymour
git-rev-list --merge-order is omitting one of the roots when displaying a merge containing two distinct roots. A subsequent patch will fix the problem. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-20[PATCH] Additional git-rev-list unit tests to demonstrate problems that ↵Jon Seymour
require fixes 1. --merge-order doesn't deal properly with a specified head that has no parent * FAIL 11: head has no parent 2. --merge-order doesn't deal properly with arguments of the form head ^head * FAIL 30: head ^head --merge-order git-rev-list --merge-order --show-breaks a3 ^a3 3. if one of the specified heads is reachable from the other, the head gets printed twice and this causes problems for upcoming versions of gitk. This is true for both --merge-order and non --merge-order style of invocations. * FAIL 24: one specified head reachable from another a4, c3, --merge-order * FAIL 26: one specified head reachable from another a4, c3, no --merge-order * FAIL 27: one specified head reachable from another c3, a4, no --merge-order 4. --merge-order aborts with commits that list the same parent should handle it more gracefully. * no longer unit testable 5. broken interaction between --merge-order and --max-age previously posted as: "[PATCH 1/2] Test case that demonstrates problem with --merge-order, --max-age interaction" * FAIL 23: --max-age=c3, --merge-order Later patches in this patch set fix these problems. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-08[PATCH] three --merge-order bug fixesJon Seymour
This patch fixes three bugs in --merge-order support * mark_ancestors_uninteresting was unnecessarily exponential which caused a problem when a commit with no parents was merged near the head of something like the linux kernel * removed a spurious statement from find_base which wasn't apparently causing problems now, but wasn't correct either. * removed an unnecessarily strict check from find_base_for_list that causes a problem if git-rev-list commit ^parent-of-commit is specified. * added some unit tests which were accidentally omitted from original merge-order patch The fix to mark_ancestors_uninteresting isn't an optimal fix - a full graph scan will still be performed in this case even though it is not strictly required. However, a full graph scan is linear and still no worse than git-rev-list HEAD which runs in less than 2 seconds on a warm cache. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>