summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2005-08-11[PATCH] Need to set PAGER in testsLibravatar Pavel Roskin1-1/+2
"t5400-send-pack.sh --verbose" stops waiting for user input. It happens because "git log" uses less for output now. To prevent this, PAGER should be set to cat. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-11[PATCH] Missing test_doneLibravatar Pavel Roskin4-0/+7
All test scripts should end with test_done, which reports the test results. In the future, it could be used for other purposes, e.g. to distinguish graceful end from "exit" in a test. This patch fixes scripts that don't call test_done. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-11String comparison of test is done with '=', not '=='.Libravatar Junio C Hamano1-4/+4
Caught this during a test setting /bin/sh to (d)ash. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-10[PATCH] Fix git-rev-parse's parent handlingLibravatar Johannes Schindelin1-0/+33
git-rev-parse HEAD^1 would fail, because of an off-by-one bug (but HEAD^ would yield the expected result). Also, when the parent does not exist, do not silently return an incorrect SHA1. Of course, this no longer applies to git-rev-parse alone, but every user of get_sha1(). While at it, add a test. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-29Skip --merge-order test when built with NO_OPENSSLLibravatar Junio C Hamano1-0/+7
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 <junkio@cox.net>
2005-07-29Documentation and tests: ls-files exclude pattern.Libravatar Junio C Hamano1-5/+18
Update the tests and documentation to match the new "last one determines its fate" semantics. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-29[PATCH] support bc version 1.04Libravatar Johannes Schindelin1-2/+6
Test t6002 unnecessarily fails when bc is a bit older than average. Signed-off-by: Johannes.Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-26Fix potential send-pack SIGSEGVLibravatar Linus Torvalds1-0/+54
The check that the source is ahead of the destination incorrectly expects pop_most_recent_commit() to gracefully handle an empty list. Fix by just checking the list itself, rather than the return value of the pop function. [jc: I did the test script that demonstrated the problem] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-26Adjust diff-raw tests to the status letter change.Libravatar Junio C Hamano18-34/+34
We use 'A' for added files instead of 'N' to make the it visually easier to distinguish from 'M' now. While we are at it, make the test scripts executable. Yes, I know it does not matter because t/Makefile runs them explicitly with "sh tXXXX-blah.sh", but being consistent is always better. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-25git-ls-files: --exclude mechanism updates.Libravatar Junio C Hamano1-0/+55
Add --exclude-per-directory=<name> option that specifies a file to contain exclude patterns local to that directory and its subdirectories. Update the exclusion logic to be able to say "include files that match this more specific pattern, even though later exclude patterns may match them". Also enhances that a pattern can contain '/' in which case fnmatch is called with FNM_PATHNAME flag to match the entire path. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-22[PATCH] Test framework: prettyprint the failed command.Libravatar Junio C Hamano1-1/+3
The output from a failure case had the test description message and the first line of the actual test script concatenated on the same line, which was ugly. Correct the output routine a bit to make it more readable. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-22[PATCH] apply.c: handle incomplete lines correctly.Libravatar Junio C Hamano1-0/+32
The parsing code had a bug that failed to recognize an incomplete line at the end of a fragment, and the fragment application code had a comparison bug to recognize such. Fix them to handle incomplete lines correctly. Add a test script for patches with various combinations of complete and incomplete lines to make sure the fix works. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] Prevent t6000 series from dropping useless sed.script in t/Libravatar Junio C Hamano5-3/+11
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, t6000-lib.sh was named to match that pattern. This caused t6000-lib.sh to be called from Makefile as the top-level program, causing it to leave t/sed.script file behind. Rename it to t6000lib.sh to prevent this, and document the naming convention a bit more clearly. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Write sed script directly into temp file, rather than a variableLibravatar Jon Seymour4-33/+7
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Add t/t6003 with some --topo-order testsLibravatar Jon Seymour1-0/+417
Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Add a t/t6001 test case for a --merge-order bugLibravatar Jon Seymour1-0/+20
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Change the sed seperator in t/t6000-lib.sh.Libravatar Jon Seymour1-1/+3
This trivial patch removes the semicolon as the sed seperator in the t/t6000-lib.sh test script and replaces it with white space. This makes BSD sed(1) much happier. Signed-off-by: Mark Allen <mrallen1@yahoo.com> Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Introduce unit tests for git-rev-list --bisectLibravatar Jon Seymour1-0/+247
This patch introduces some unit tests for the git-rev-list --bisect functionality. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-06[PATCH] Factor out useful test case infrastructure from t/t6001... into ↵Libravatar Jon Seymour2-111/+106
t/t6000-lib.sh Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh To use these functions in a test case, use a test-case pre-amble like: . ./test-lib.sh . ../t6000-lib.sh # t6xxx specific functions Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-04[PATCH] Fixup t/t5300 unit tests broken by ↵Libravatar Jon Seymour1-15/+15
5f3de58ff85c49620ae2a1722d8d4d37c881a054 This patch fixes up the t/t5300 unit tests which were broken by the changes in: Make the name of a pack-file depend on the objects packed there-in. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Remove unnecessary sort from t6001 testcaseLibravatar Jon Seymour1-8/+8
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Fix broken t6001 test caseLibravatar Jon Seymour1-3/+3
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Demonstrate broken t6001 test case functionLibravatar Jon Seymour1-3/+2
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]Libravatar Jon Seymour1-6/+6
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Test case that demonstrates problem with --merge-order ^ processingLibravatar Jon Seymour1-0/+5
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Adjust t5300 test for unpack-objects changeLibravatar Junio C Hamano1-2/+4
It now always read from standard input and rejects non-flag arguments. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Add git-verify-pack command.Libravatar Junio C Hamano1-0/+38
Given a list of <pack>.idx files, this command validates the index file and the corresponding .pack file for consistency. This patch also uses the same validation mechanism in fsck-cache when the --full flag is used. During normal operation, sha1_file.c verifies that a given .idx file matches the .pack file by comparing the SHA1 checksum stored in .idx file and .pack file as a minimum sanity check. We may further want to check the pack signature and version when we map the pack, but that would be a separate patch. Earlier, errors to map a pack file was not flagged fatal but led to a random fatal error later. This version explicitly die()s when such an error is detected. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27Fix another test that broke with the recent git-init-db updateLibravatar Linus Torvalds1-1/+0
t5300-pack-object.sh test 8 expected to have to create the "pack" directory itself, and was unhappy when it already existed.
2005-06-27[PATCH] replace sha1sum with sum in t/t1002Libravatar Mark Allen1-15/+32
This replaces sha1sum(1) with sum(1) in t/t1002. GNU sum(1) runs in "BSD compatibility" mode by default, and not all systems have GNU coreutils. On any system without GNU coreutils (or sha1sum) t1002 will fail. This patch should make t1002 complete successfully everywhere that sum(1) runs. I've tested this on Darwin and Linux; it works on both platforms. Signed-off-by: Mark Allen <mrallen1@yahoo.com> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27Fix up test that counted subdirectories in ".git/objects"Libravatar Linus Torvalds1-3/+3
Now there are 257 of them (256 numeric ones, and the new "pack" directory)
2005-06-27[PATCH] Teach read_sha1_file() and friends about packed git object store.Libravatar Junio C Hamano1-2/+46
GIT_OBJECT_DIRECTORY and GIT_ALTERNATE_OBJECT_DIRECTORIES can have the "pack" subdirectory that houses "packed GIT" files produced by git-pack-objects (e.g. .git/objects/pack/foo.pack and .git/objects/pack/foo.idx; always store them as pairs). The following functions in sha1_file.c can then read object contents from such packed file: - sha1_object_info() - has_sha1_file() - read_sha1_file() Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] Remove "delta" object representation.Libravatar Junio C Hamano1-79/+0
Packed delta files created by git-pack-objects seems to be the way to go, and existing "delta" object handling code has exposed the object representation details to too many places. Remove it while we refactor code to come up with a proper interface in sha1_file.c. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26[PATCH] Finish initial cut of git-pack-object/git-unpack-object pair.Libravatar Junio C Hamano1-0/+85
This finishes the initial round of git-pack-object / git-unpack-object pair. They are now good enough to be used as a transport medium: - Fix delta direction in pack-objects; the original was computing delta to create the base object from the object to be squashed, which was quite unfriendly for unpacker ;-). - Add a script to test the very basics. - Implement unpacker for both regular and deltified objects. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] Fix oversimplified optimization for add_cache_entry().Libravatar Junio C Hamano1-5/+20
An earlier change to optimize directory-file conflict check broke what "read-tree --emu23" expects. This is fixed by this commit. (1) Introduces an explicit flag to tell add_cache_entry() not to check for conflicts and use it when reading an existing tree into an empty stage --- by definition this case can never introduce such conflicts. (2) Makes read-cache.c:has_file_name() and read-cache.c:has_dir_name() aware of the cache stages, and flag conflict only with paths in the same stage. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] Add more tests for read-tree --emu23.Libravatar Junio C Hamano2-14/+150
This adds more tests for --emu23. One is to show how it can carry forward more local changes than the straightforward two-way fast forward, and another is to show the recent overeager optimization of directory/file conflict check broke things, which will be fixed in the next commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-22[PATCH] A test case that demonstrates a problem with merges with two roots.Libravatar Jon Seymour1-0/+61
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-22[PATCH] git-apply: tests for --stat and --summary.Libravatar Junio C Hamano15-0/+2152
This adds tests (which also serves demonstration) for the --stat and --summary flags to the git-apply command. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-19[PATCH] Additional git-rev-list unit tests to demonstrate problems that ↵Libravatar Jon Seymour1-61/+375
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 twice...it 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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-19[PATCH] Rework -B output.Libravatar Junio C Hamano1-21/+15
Patch for a completely rewritten file detected by the -B flag was shown as a pair of creation followed by deletion in earlier versions. This was an misguided attempt to make reviewing such a complete rewrite easier, and unnecessarily ended up confusing git-apply. Instead, show the entire contents of old version prefixed with '-', followed by the entire contents of new version prefixed with '+'. This gives the same easy-to-review for human consumer while keeping it a single, regular modification patch for machine consumption, something that even GNU patch can grok. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-19[PATCH] Make -C less eager.Libravatar Junio C Hamano4-4/+5
Like diff-tree, this patch makes -C option for diff-* brothers to use only pre-image of modified files as rename/copy detection by default. Give --find-copies-harder to use unmodified files to find copies from as well. This also fixes "diff-files -C" problem earlier noticed by Linus. It was feeding the null sha1 even when the file in the work tree was known to match what is in the index file. This resulted in diff-files showing everything in the project. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-14[PATCH] Unset TZ in t5000Libravatar Mark Allen1-2/+3
Unset TZ to force GMT in test #4 and add a set of parens around the length function in the awk script. Signed-off-by: Mark Allen <mrallen1@yahoo.com> Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] read-tree: loosen too strict index requirementsLibravatar Junio C Hamano1-0/+9
This patch teaches read-tree 3-way merge that, when only "the other tree" changed a path, and if the index file already has the same change, we are not in a situation that would clobber the index and the work tree, and lets the merge succeed; this is case #14ALT in t1000 test. It does not change the result of the merge, but prevents it from failing when it does not have to. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Finish making --emu23 equivalent to pure 2-way merge.Libravatar Junio C Hamano2-16/+36
This adds #3ALT rule (and #2ALT rule for symmetry) to the read-tree 3-way merge logic that collapses paths that are added only in one branch and not in the other internally. This makes --emu23 to succeed in the last remaining case where the pure 2-way merge succeeded and earlier one failed. Running diff between t1001 and t1005 test scripts shows that the only difference between the two is that --emu23 can leave the states into separate stages so that the user can use usual 3-way merge resolution techniques to carry forward the local changes when pure 2-way merge would have refused to run. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] read-tree: fix too strong index requirement #5ALTLibravatar Junio C Hamano2-13/+13
This fixes too strong index requirement 3-way merge enforces in one case: the same file is added in both branches. In this case, the original code insisted that if the index file has that path, it must match our branch and be up-to-date. However in this particular case, it only has to match it, and can be dirty. We just need to make sure that we keep the work-tree copy instead of checking out the merge result. The resolution of such a path, however, cannot be left to outside script, because we will not keep the original stage0 entries for unmerged paths when read-tree finishes, and at that point, the knowledge of "if we resolve it to match the new file added in both branches, the merge succeeds and the work tree would not lose information, but we should _not_ update the work tree from the resulting index file" is lost. For this reason, the now code needs to resolve this case (#5ALT) internally. This affects some existing tests in the test suite, but all in positive ways. In t1000 (3-way test), this #5ALT case now gets one stage0 entry, instead of an identical stage2 and stage3 entry pair, for such a path, and one test that checked for merge failure (because the test assumed the "stricter-than-necessary" behaviour) does not have to fail anymore. In t1005 (emu23 test), two tests that involves a case where the work tree already had a change introduced in the upstream (aka "merged head"), the merge succeeds instead of failing. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] read-tree --emu23.Libravatar Junio C Hamano1-0/+316
This new flag causes two-way fast forward to internally use the three-way merge mechanism. This behaviour is intended to offer a better fast forward semantics when used in a dirty work tree. The new test t1005 is parallel to the existing t1001 "pure 2-way" tests, but some parts that are commented out would fail. These failures are due to three-way merge enforcing too strict index requirements for cases that could succeed. This problem will be addressed by later patches. Without even changing three-way mechanism, the --emu23 two-way fast forward already gives the user an easier-to-handle merge result when a file that "merged head" updates has local modifications. This is demonstrated as "case 16" test in t1005. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Clean up read-tree two-way tests.Libravatar Junio C Hamano1-35/+42
This is in preparation for "2-way fast-forward emulated with 3-way mechanism" series. It does not change what the tests for pure 2-way do. It only changes how it tests things, to make reviewing of differences of the two tests easier in later steps. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08[PATCH] Add read-tree -m 3-way merge tests.Libravatar Junio C Hamano2-12/+366
This adds a set of tests to make sure that requirements on existing cache entries are checked when a read-tree -m 3-way merge is run with an already populated index file. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08[PATCH] Tests: read-tree -m test updates.Libravatar Junio C Hamano2-32/+30
This updates t1000 (basic 3-way merge test) to check the merge results for both successful cases (earlier one checked the result for only one of them). Also fixes typos in t1002 that broke '&&' chain, potentially missing a test failure before the chain got broken. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08[PATCH] three --merge-order bug fixesLibravatar Jon Seymour1-0/+175
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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-07[PATCH] read-tree: save more user hassles during fast-forward.Libravatar Junio C Hamano2-0/+588
This implements the "never lose the current cache information or the work tree state, but favor a successful merge over merge failure" principle in the fast-forward two-tree merge operation. It comes with a set of tests to cover all the cases described in the case matrix found in the new documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>