summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
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>
2005-06-05[PATCH] 3-way merge tests for new "git-read-tree -m"?Libravatar Junio C Hamano1-1/+18
The updated git-tread-tree -m is more strict in that it wants to have the original cache up to date. The initial part of t1000 (merge tests from hell) fails due to it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-05diff 'rename' format change.Libravatar Linus Torvalds5-10/+10
Clearly even Junio felt git "rename" header lines should say "from/to" instead of "old/new", since he wrote the documentation that way. This way it also matches "copy". git-apply will accept both versions, at least for a while.
2005-06-05[PATCH] pull: gracefully recover from delta retrieval failure.Libravatar Junio C Hamano1-0/+79
This addresses a concern raised by Jason McMullan in the mailing list discussion. After retrieving and storing a potentially deltified object, pull logic tries to check and fulfil its delta dependency. When the pull procedure is killed at this point, however, there was no easy way to recover by re-running pull, since next run would have found that we already have that deltified object and happily reported success, without really checking its delta dependency is satisfied. This patch introduces --recover option to git-*-pull family which causes them to re-validate dependency of deltified objects we are fetching. A new test t5100-delta-pull.sh covers such a failure mode. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-03[PATCH] git-tar-tree: do only basic tests in t/t5000-git-tar-tree.shLibravatar Rene Scharfe1-20/+7
git-tar-tree: remove tests of long path handling out of t5000-tar-tree.sh and make test script cope with tar programs displaying file modification date as hh:mm (newer variants show it as hh:mm:ss). This makes the test cover only basic functionality that is expected to be handled even by older tar programs. Tests for long filenames (which require pax extended headers) can be added separately. I ran this test successfully with GNU tar 1.13, 1.14 and 1.15.1. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-02[PATCH] git-tar-tree: add a test caseLibravatar Rene Scharfe1-0/+106
add a simple test case. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-31[PATCH] ls-tree: handle trailing slashes in the pathspec properly.Libravatar Junio C Hamano2-5/+99
This fixes the problem with ls-tree which failed to show "drivers/char" directory when the user asked for "drivers/char/" from the command line. At the same time, if "drivers/char" were a non directory, "drivers/char/" would not show it. This is consistent with the way diffcore-pathspec has been recently fixed. This adds back the diffcore-pathspec test,dropped when my earlier diffcore-pathspec fix was rejected. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-31[PATCH] diff: consolidate test helper script pieces.Libravatar Junio C Hamano6-83/+43
There were duplicate script pieces to help comparing diff output, which this patch consolidates into the t/diff-lib.sh library. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30[PATCH] Add -B flag to diff-* brothers.Libravatar Junio C Hamano1-0/+207
A new diffcore transformation, diffcore-break.c, is introduced. When the -B flag is given, a patch that represents a complete rewrite is broken into a deletion followed by a creation. This makes it easier to review such a complete rewrite patch. The -B flag takes the same syntax as the -M and -C flags to specify the minimum amount of non-source material the resulting file needs to have to be considered a complete rewrite, and defaults to 99% if not specified. As the new test t4008-diff-break-rewrite.sh demonstrates, if a file is a complete rewrite, it is broken into a delete/create pair, which can further be subjected to the usual rename detection if -M or -C is used. For example, if file0 gets completely rewritten to make it as if it were rather based on file1 which itself disappeared, the following happens: The original change looks like this: file0 --> file0' (quite different from file0) file1 --> /dev/null After diffcore-break runs, it would become this: file0 --> /dev/null /dev/null --> file0' file1 --> /dev/null Then diffcore-rename matches them up: file1 --> file0' The internal score values are finer grained now. Earlier maximum of 10000 has been raised to 60000; there is no user visible changes but there is no reason to waste available bits. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30[PATCH] diff-helper: Fix R/C score parsing under -z flag.Libravatar Junio C Hamano3-8/+210
The score number that follow R/C status were parsed but the parse pointer was not updated, causing the entire line to become unrecognized. This patch fixes this problem. There was a test missing to catch this breakage, which this commit adds as t4009-diff-rename-4.sh. The diff-raw tests used in related t4005-diff-rename-2.sh (the same test without -z) and t4007-rename-3.sh were stricter than necessarily, despite that the comment for the tests said otherwise. This patch also corrects them. The documentation is updated to say that the status can optionally be followed by a number called "score"; it does not have to stay similarity index forever and there is no reason to limit it only to C and R. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-29[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a"Libravatar Junio C Hamano1-2/+1
This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-29[PATCH] Move pathspec to the beginning of the diffcore chain.Libravatar Junio C Hamano1-11/+11
This changes the way how pathspec is used in the three diff-* brothers. Earlier, they tried to grab as much information from the original input and used pathspec to limit the output. This version uses pathspec upfront to narrow the world diffcore operates in, so "git-diff-* <arguments> some-directory" does not look at things outside the specified subtree when finding rename/copy or running pickaxe. Since diff-tree already takes this view and does not feed anything outside the specified directotires to begin with, this patch does not have to touch that command. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-29[PATCH] Fix the way diffcore-rename records unremoved source.Libravatar Junio C Hamano1-0/+103
Earier version of diffcore-rename used to keep unmodified filepair in its output so that the last stage of the processing that tells renames from copies can make all of rename/copy to copies. However this had a bad interaction with other diffcore filters that wanted to run after diffcore-rename, in that such unmodified filepair must be retained for proper distinction between renames and copies to happen. This patch fixes the problem by changing the way diffcore-rename records the information needed to distinguish "all are copies" case and "the last one is a rename" case. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-26[PATCH] fix and testcase for git-commit-tree optionLibravatar Rene Scharfe1-0/+45
Actually use GIT_COMMITTER_DATE in git-commit-tree. (It used to mistakenly re-use the author date) Add test-case for it. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-26[PATCH] Make ls-* output consistent with diff-* output format.Libravatar Junio C Hamano3-92/+92
Use SP as the column separator except the ones before path which uses TAB, to make the output format consistent across ls-* and diff-* commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-26[PATCH] ls-tree matching multiple pathsLibravatar Jason McMullan1-0/+103
Enhance git-ls-tree to allow optional 'match paths' that restricts the output of git-ls-tree. This is useful to retrieve a single file's SHA1 out of a tree without creating an index. [JC: I added the test case] Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-25[PATCH] Test case portability fix.Libravatar Mark Allen2-5/+3
This is the remainder of testcase fix by Mark Allen to make them work on his Darwin box. I was using "xargs -r" (GNU) where it was not needed, sed -ne '/^\(author\|committer\)/s|>.*|>|p' where some sed does not know what to do with '\|', and also "cmp - file" to compare standard input with a file, which his cmp does not support. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-25[PATCH] Mode only changes from diff.Libravatar Junio C Hamano1-0/+34
This fixes another bug. - Mode-only changes were pruned incorrectly from the output. - Added test to catch the above problem. - Normalize rename/copy similarity score in the diff-raw output to per-cent, no matter what scale we internally use. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-25[PATCH] Adjust show-files test for dotfiles.Libravatar Junio C Hamano1-3/+4
The earlier test was relying on the fact that dotfiles do not appear in the output to prepare expected test results, which inevitably got broken when we started handling dotfiles. Change the test to be honest about what "--other" file it creates. The problem was originally pointed out by Mark Allen. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-24[PATCH] Allow symlinks in the leading path in checkout-cache --prefix=Libravatar Junio C Hamano1-0/+95
This is what Linus wrote, improving what David Greaves originally submitted. I just added a test case and verified the patch works. Author: David Greaves <david@dgreaves.com> Author: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-24[PATCH] Redo rename/copy detection logic.Libravatar Junio C Hamano3-24/+24
Earlier implementation had a major screw-up in the memory management area. Rename/copy logic sometimes borrowed a pointer to a structure without any provision for downstream to determine which pointer is shared and which is not. This resulted in the later clean-up code to sometimes double free such structure, resulting in a segfault. This made -M and -C useless. Another problem the earlier implementation had was that it reordered the patches, and forced the logic to differentiate renames and copies to depend on that particular order. This problem was fixed by teaching rename/copy detection logic not to do any reordering, and rename-copy differentiator not to depend on the order of the patches. The diffs will leave rename/copy detector in the same destination path order as the patch that was fed into it. Some test vectors have been reordered to accommodate this change. It also adds a sanity check logic to the human-readable diff-raw output to detect paths with embedded TAB and LF characters, which cannot be expressed with that format. This idea came up during a discussion with Chris Wedgwood. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23[PATCH] Fix diff-pruning logic which was running prune too early.Libravatar Junio C Hamano1-4/+3
For later stages to reorder patches, pruning logic and rename detection logic should not decide which delete to discard (because another entry said it will take over the file as a rename) until the very end. Also fix some tests that were assuming the earlier "last one is rename or keep everything else is copy" semantics of diff-raw format, which no longer is true. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23[PATCH] diff-raw format update take #2.Libravatar Junio C Hamano4-175/+276
This changes the diff-raw format again, following the mailing list discussion. The new format explicitly expresses which one is a rename and which one is a copy. The documentation and tests are updated to match this change. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23[PATCH] Rename/copy detection fix.Libravatar Junio C Hamano2-11/+97
The rename/copy detection logic in earlier round was only good enough to show patch output and discussion on the mailing list about the diff-raw format updates revealed many problems with it. This patch fixes all the ones known to me, without making things I want to do later impossible, mostly related to patch reordering. (1) Earlier rename/copy detector determined which one is rename and which one is copy too early, which made it impossible to later introduce diffcore transformers to reorder patches. This patch fixes it by moving that logic to the very end of the processing. (2) Earlier output routine diff_flush() was pruning all the "no-change" entries indiscriminatingly. This was done due to my false assumption that one of the requirements in the diff-raw output was not to show such an entry (which resulted in my incorrect comment about "diff-helper never being able to be equivalent to built-in diff driver"). My special thanks go to Linus for correcting me about this. When we produce diff-raw output, for the downstream to be able to tell renames from copies, sometimes it _is_ necessary to output "no-change" entries, and this patch adds diffcore_prune() function for doing it. (3) Earlier diff_filepair structure was trying to be not too specific about rename/copy operations, but the purpose of the structure was to record one or two paths, which _was_ indeed about rename/copy. This patch discards xfrm_msg field which was trying to be generic for this wrong reason, and introduces a couple of fields (rename_score and rename_rank) that are explicitly specific to rename/copy logic. One thing to note is that the information in a single diff_filepair structure _still_ does not distinguish renames from copies, and it is deliberately so. This is to allow patches to be reordered in later stages. (4) This patch also adds some tests about diff-raw format output and makes sure that necessary "no-change" entries appear on the output. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23[PATCH] Be careful with symlinks when detecting renames and copies.Libravatar Junio C Hamano1-0/+66
Earlier round was not treating symbolic links carefully enough, and would have produced diff output that renamed/copied then edited the contents of a symbolic link, which made no practical sense. Change it to detect only pure renames. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-21[PATCH] The diff-raw format updates.Libravatar Junio C Hamano3-116/+115
Update the diff-raw format as Linus and I discussed, except that it does not use sequence of underscore '_' letters to express nonexistence. All '0' mode is used for that purpose instead. The new diff-raw format can express rename/copy, and the earlier restriction that -M and -C _must_ be used with the patch format output is no longer necessary. The patch makes -M and -C flags independent of -p flag, so you need to say git-whatchanged -M -p to get the diff/patch format. Updated are both documentations and tests. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-21t/t4003-diff-rename-1: use modern options to "diff"Libravatar Linus Torvalds1-3/+3
Don't do "-u0", use "--unified=0" which is accepted by modern GNU diff versions.
2005-05-21[PATCH] Diff overhaul, adding the other half of copy detection.Libravatar Junio C Hamano1-1/+37
This patch extends diff-cache and diff-files to report the unmodified files to diff-core as well when -C (copy detection) is in effect, so that the unmodified files can also be used as the source candidates. The existing test t4003 has been extended to cover this case. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>