{"thread":{"id":"17912","subject":"[PATCH 1/4] Start a library for cvsimport-related tests","startedAt":"2009-02-20T05:18:09Z","lastAt":"2009-02-24T17:01:05Z","messageCount":24,"participants":["Michael Haggerty","Jeff King","Junio C Hamano","Ferry Huberts (Pelagic)","Johannes Schindelin","Jakub Narebski","Samuel Lucas Vaz de Mello"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"105559","messageId":"1235107093-32605-1-git-send-email-mhagger@alum.mit.edu","threadId":"17912","inReplyTo":null,"subject":"[PATCH 0/4] Add more tests of cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T05:18:09Z","receivedAt":"2009-02-20T05:18:09Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"The test suite for \"git cvsimport\" is pretty limited, and I would like\nto improve the situation. This patch series contains the first of\nwhat I hope will eventually be several additions to the \"git\ncvsimport\" test suite.\n\nI am the maintainer of cvs2svn/cvs2git. Most of the new tests will\nprobably use fragments from the cvs2svn test suite. I should admit\nthat part of my motivation for adding tests to the \"git cvsimport\"\ntest suite is to document its weaknesses, which do not seem to be\nespecially well known.\n\nPatch 1 splits out some code into a library usable by multiple\nCVS-related tests.\n\nPatch 2 changes the library to add the -f option when invoking cvs (to\nmake it ignore the user's ~/.cvsrc file).\n\nPatch 3 adds a new test to t9600, namely to compare the entire module\nas checked out by CVS vs. git.\n\nPatch 4 adds a new test script t9601 that tests \"git cvsimport\"'s\nhandling of CVS vendor branches. One of these tests fails due to an\nactual bug.\n\nThese ideas in the patches are logically independent of each other,\nbut each patch assumes that the previous patches have been applied.\n\nI would like to point out a few things about these patches that seem a\nlittle bit unprecedented in the git test suite. If other approaches\nwould be preferred, please let me know.\n\nThe first is that I would like to introduce a library that can be used\nby the \"git cvsimport\" tests in the t96xx series, simply to avoid code\nduplication. I put this library in t/t96xx/cvs-lib.sh, to hopefully\nmake its role clear. The library has to be sourced from the main test\ndirectory. (It sources test-lib.sh indirectly.)\n\nThe second is that the new test script uses a small CVS repository\nthat is part of the test suite (i.e., the *,v files are committed\ndirectly into the git source tree). This is different than the\napproach of t9600, which creates its own test CVS repository using CVS\ncommands. The reasons for this are:\n\n- t9600 wants to test incremental import, so it *has to* create the\n repository dynamically. That is not the case for t9601, which only\n tests a one-shot import.\n\n- The repository for t9601 is derived from one that already exists as\n part of the cvs2svn test suite. Reverse-engineering it into CVS\n commands would be extra work.\n\n- The code to create CVS repositories via CVS commands is not very\n illuminating, and runs slowly, as CVS throttles commits to 1 per\n second (to ensure unique timestamps).\n\n- Future tests may require even more complicated CVS repositories that\n are even more cumbersome to create, so it's good to set a precedent\n now :-)\n\nFinally, the *,v files comprising the CVS repository have blank\ntrailing lines, triggering a warning from \"git diff --check\". I don't\nthink that CVS strictly requires the blank lines, but they are always\ngenerated by CVS, so I left them in. But if the \"git diff --check\"\nwarnings are considered a serious problem, the blank lines could\nprobably be removed.\n\nCheers,\nMichael\n"},{"id":"105556","messageId":"c3466ee438cd4a5e9d08479ef127468981d4c293.1235106222.git.mhagger@alum.mit.edu","threadId":"17912","inReplyTo":"1235107093-32605-1-git-send-email-mhagger@alum.mit.edu","subject":"[PATCH 1/4] Start a library for cvsimport-related tests","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T05:18:10Z","receivedAt":"2009-02-20T05:18:10Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"For now the \"library\" just includes code (moved from\nt/t9600-cvsimport.sh) that checks whether the prerequisites for \"git\ncvsimport\" are installed.\n\nSigned-off-by: Michael Haggerty \n---\n t/t9600-cvsimport.sh | 29 +----------------------------\n t/t96xx/cvs-lib.sh | 31 +++++++++++++++++++++++++++++++\n 2 files changed, 32 insertions(+), 28 deletions(-)\n create mode 100644 t/t96xx/cvs-lib.sh\n\ndiff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh\nindex d2379e7..b4b9896 100755\n--- a/t/t9600-cvsimport.sh\n+++ b/t/t9600-cvsimport.sh\n@@ -1,37 +1,10 @@\n #!/bin/sh\n \n test_description='git cvsimport basic tests'\n-. ./test-lib.sh\n+. ./t96xx/cvs-lib.sh\n \n CVSROOT=$(pwd)/cvsroot\n export CVSROOT\n-unset CVS_SERVER\n-# for clean cvsps cache\n-HOME=$(pwd)\n-export HOME\n-\n-if ! type cvs >/dev/null 2>&1\n-then\n-\tsay 'skipping cvsimport tests, cvs not found'\n-\ttest_done\n-\texit\n-fi\n-\n-cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`\n-case \"$cvsps_version\" in\n-2.1 | 2.2*)\n-\t;;\n-'')\n-\tsay 'skipping cvsimport tests, cvsps not found'\n-\ttest_done\n-\texit\n-\t;;\n-*)\n-\tsay 'skipping cvsimport tests, unsupported cvsps version'\n-\ttest_done\n-\texit\n-\t;;\n-esac\n \n test_expect_success 'setup cvsroot' 'cvs init'\n \ndiff --git a/t/t96xx/cvs-lib.sh b/t/t96xx/cvs-lib.sh\nnew file mode 100644\nindex 0000000..bfc1c12\n--- /dev/null\n+++ b/t/t96xx/cvs-lib.sh\n@@ -0,0 +1,31 @@\n+#!/bin/sh\n+\n+. ./test-lib.sh\n+\n+unset CVS_SERVER\n+# for clean cvsps cache\n+HOME=$(pwd)\n+export HOME\n+\n+if ! type cvs >/dev/null 2>&1\n+then\n+\tsay 'skipping cvsimport tests, cvs not found'\n+\ttest_done\n+\texit\n+fi\n+\n+cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`\n+case \"$cvsps_version\" in\n+2.1 | 2.2*)\n+\t;;\n+'')\n+\tsay 'skipping cvsimport tests, cvsps not found'\n+\ttest_done\n+\texit\n+\t;;\n+*)\n+\tsay 'skipping cvsimport tests, unsupported cvsps version'\n+\ttest_done\n+\texit\n+\t;;\n+esac\n-- \n1.6.1.3\n"},{"id":"105560","messageId":"c202fb4c8c1eb0121cc15df6ad4a600dc3074f21.1235106222.git.mhagger@alum.mit.edu","threadId":"17912","inReplyTo":"c3466ee438cd4a5e9d08479ef127468981d4c293.1235106222.git.mhagger@alum.mit.edu","subject":"[PATCH 2/4] Use CVS's -f option if available (ignore user's ~/.cvsrc file)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T05:18:11Z","receivedAt":"2009-02-20T05:18:11Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"A user's ~/.cvsrc file can change the basic behavior of CVS commands.\nTherefore we should ignore it in order to ensure consistent results\nfrom the test suite.\n\nSigned-off-by: Michael Haggerty \n---\n t/t9600-cvsimport.sh | 16 ++++++++--------\n t/t96xx/cvs-lib.sh | 3 +++\n 2 files changed, 11 insertions(+), 8 deletions(-)\n\ndiff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh\nindex b4b9896..66393ae 100755\n--- a/t/t9600-cvsimport.sh\n+++ b/t/t9600-cvsimport.sh\n@@ -6,12 +6,12 @@ test_description='git cvsimport basic tests'\n CVSROOT=$(pwd)/cvsroot\n export CVSROOT\n \n-test_expect_success 'setup cvsroot' 'cvs init'\n+test_expect_success 'setup cvsroot' '$CVS init'\n \n test_expect_success 'setup a cvs module' '\n \n \tmkdir \"$CVSROOT/module\" &&\n-\tcvs co -d module-cvs module &&\n+\t$CVS co -d module-cvs module &&\n \tcd module-cvs &&\n \tcat <o_fortuna &&\n O Fortuna\n@@ -30,13 +30,13 @@ egestatem,\n potestatem\n dissolvit ut glaciem.\n EOF\n-\tcvs add o_fortuna &&\n+\t$CVS add o_fortuna &&\n \tcat <message &&\n add \"O Fortuna\" lyrics\n \n These public domain lyrics make an excellent sample text.\n EOF\n-\tcvs commit -F message &&\n+\t$CVS commit -F message &&\n \tcd ..\n '\n \n@@ -74,7 +74,7 @@ translate to English\n \n My Latin is terrible.\n EOF\n-\tcvs commit -F message &&\n+\t$CVS commit -F message &&\n \tcd ..\n '\n \n@@ -92,8 +92,8 @@ test_expect_success 'update cvs module' '\n \n \tcd module-cvs &&\n \t\techo 1 >tick &&\n-\t\tcvs add tick &&\n-\t\tcvs commit -m 1\n+\t\t$CVS add tick &&\n+\t\t$CVS commit -m 1\n \tcd ..\n \n '\n@@ -111,7 +111,7 @@ test_expect_success 'cvsimport.module config works' '\n \n test_expect_success 'import from a CVS working tree' '\n \n-\tcvs co -d import-from-wt module &&\n+\t$CVS co -d import-from-wt module &&\n \tcd import-from-wt &&\n \t\tgit cvsimport -a -z0 &&\n \t\techo 1 >expect &&\ndiff --git a/t/t96xx/cvs-lib.sh b/t/t96xx/cvs-lib.sh\nindex bfc1c12..6738901 100644\n--- a/t/t96xx/cvs-lib.sh\n+++ b/t/t96xx/cvs-lib.sh\n@@ -14,6 +14,9 @@ then\n \texit\n fi\n \n+CVS=\"cvs -f\"\n+export CVS\n+\n cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`\n case \"$cvsps_version\" in\n 2.1 | 2.2*)\n-- \n1.6.1.3\n"},{"id":"105557","messageId":"78a9942d20fa6315deb723316b757cc635292ee2.1235106222.git.mhagger@alum.mit.edu","threadId":"17912","inReplyTo":"c202fb4c8c1eb0121cc15df6ad4a600dc3074f21.1235106222.git.mhagger@alum.mit.edu","subject":"[PATCH 3/4] Test contents of entire cvsimported \"master\" tree contents","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T05:18:12Z","receivedAt":"2009-02-20T05:18:12Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Test added for completeness (it passes).\n\nSigned-off-by: Michael Haggerty \n---\n t/t9600-cvsimport.sh | 2 ++\n t/t96xx/cvs-lib.sh | 25 +++++++++++++++++++++++++\n 2 files changed, 27 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh\nindex 66393ae..dad9d49 100755\n--- a/t/t9600-cvsimport.sh\n+++ b/t/t9600-cvsimport.sh\n@@ -121,4 +121,6 @@ test_expect_success 'import from a CVS working tree' '\n \n '\n \n+test_expect_success 'test entire HEAD' 'test_cmp_branch_tree master'\n+\n test_done\ndiff --git a/t/t96xx/cvs-lib.sh b/t/t96xx/cvs-lib.sh\nindex 6738901..0136b36 100644\n--- a/t/t96xx/cvs-lib.sh\n+++ b/t/t96xx/cvs-lib.sh\n@@ -32,3 +32,28 @@ case \"$cvsps_version\" in\n \texit\n \t;;\n esac\n+\n+test_cvs_co () {\n+\t# Usage: test_cvs_co BRANCH_NAME\n+\tif [ \"$1\" = \"master\" ]\n+\tthen\n+\t\t$CVS co -P -d module-cvs-\"$1\" -A module\n+\telse\n+\t\t$CVS co -P -d module-cvs-\"$1\" -b \"$1\" module\n+\tfi\n+}\n+\n+test_git_co_branch () {\n+\t# Usage: test_git_co BRANCH_NAME\n+\t(cd module-git && git checkout \"$1\")\n+}\n+\n+test_cmp_branch_tree () {\n+\t# Usage: test_cmp_branch_tree BRANCH_NAME\n+\t# Check BRANCH_NAME out of CVS and git and make sure that all\n+\t# of the files and directories are identical.\n+\n+\ttest_cvs_co \"$1\" &&\n+\ttest_git_co_branch \"$1\" &&\n+\tdiff -r -x .git -x CVS module-cvs-\"$1\" module-git\n+}\n-- \n1.6.1.3\n"},{"id":"105558","messageId":"5a4785327f2d24178190e0d55e4796476a55952c.1235106222.git.mhagger@alum.mit.edu","threadId":"17912","inReplyTo":"78a9942d20fa6315deb723316b757cc635292ee2.1235106222.git.mhagger@alum.mit.edu","subject":"[PATCH 4/4] Add some tests of git-cvsimport's handling of vendor branches","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T05:18:13Z","receivedAt":"2009-02-20T05:18:13Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"CVS's handling of vendor branches is tricky; add some tests to check\nwhether revisions added via \"cvs imports\" then imported to git via\n\"git cvsimport\" are reflected correctly on master.\n\nOne of these tests fail and is therefore marked \"test_expect_failure\".\nCvsimport doesn't realize that subsequent changes on a vendor branch\naffect master as long as the vendor branch is the default branch.\n\nThe test CVS repository used for these tests is derived from cvs2svn's\ntest suite.\n\nSigned-off-by: Michael Haggerty \n---\n t/t9601-cvsimport-vendor-branch.sh | 86 ++++++++++++++++++++\n t/t9601/cvsroot/CVSROOT/.gitignore | 1 +\n t/t9601/cvsroot/module/added-imported.txt,v | 44 ++++++++++\n t/t9601/cvsroot/module/imported-anonymously.txt,v | 42 ++++++++++\n .../module/imported-modified-imported.txt,v | 76 +++++++++++++++++\n t/t9601/cvsroot/module/imported-modified.txt,v | 59 +++++++++++++\n t/t9601/cvsroot/module/imported-once.txt,v | 43 ++++++++++\n t/t9601/cvsroot/module/imported-twice.txt,v | 60 ++++++++++++++\n t/t96xx/cvs-lib.sh | 6 ++\n 9 files changed, 417 insertions(+), 0 deletions(-)\n create mode 100755 t/t9601-cvsimport-vendor-branch.sh\n create mode 100644 t/t9601/cvsroot/CVSROOT/.gitignore\n create mode 100644 t/t9601/cvsroot/module/added-imported.txt,v\n create mode 100644 t/t9601/cvsroot/module/imported-anonymously.txt,v\n create mode 100644 t/t9601/cvsroot/module/imported-modified-imported.txt,v\n create mode 100644 t/t9601/cvsroot/module/imported-modified.txt,v\n create mode 100644 t/t9601/cvsroot/module/imported-once.txt,v\n create mode 100644 t/t9601/cvsroot/module/imported-twice.txt,v\n\ndiff --git a/t/t9601-cvsimport-vendor-branch.sh b/t/t9601-cvsimport-vendor-branch.sh\nnew file mode 100755\nindex 0000000..179898b\n--- /dev/null\n+++ b/t/t9601-cvsimport-vendor-branch.sh\n@@ -0,0 +1,86 @@\n+#!/bin/sh\n+\n+# Description of the files in the repository:\n+#\n+# imported-once.txt:\n+#\n+# Imported once. 1.1 and 1.1.1.1 should be identical.\n+#\n+# imported-twice.txt:\n+#\n+# Imported twice. HEAD should reflect the contents of the\n+# second import (i.e., have the same contents as 1.1.1.2).\n+#\n+# imported-modified.txt:\n+#\n+# Imported, then modified on HEAD. HEAD should reflect the\n+# modification.\n+#\n+# imported-modified-imported.txt:\n+#\n+# Imported, then modified on HEAD, then imported again.\n+#\n+# added-imported.txt,v:\n+#\n+# Added with 'cvs add' to create 1.1, then imported with\n+# completely different contents to create 1.1.1.1, therefore the\n+# vendor branch was never the default branch.\n+#\n+# imported-anonymously.txt:\n+#\n+# Like imported-twice.txt, but with a vendor branch whose branch\n+# tag has been removed.\n+\n+test_description='git cvsimport handling of vendor branches'\n+. ./t96xx/cvs-lib.sh\n+\n+CVSROOT=\"$TEST_DIRECTORY\"/t9601/cvsroot\n+export CVSROOT\n+\n+test_expect_success 'import a module with a vendor branch' '\n+\n+\tgit cvsimport -C module-git module\n+\n+'\n+\n+test_expect_success 'check HEAD out of cvs repository' 'test_cvs_co master'\n+\n+test_expect_success 'check master out of git repository' 'test_git_co_branch master'\n+\n+test_expect_success 'check a file that was imported once' '\n+\n+\ttest_cmp_branch_file master imported-once.txt\n+\n+'\n+\n+test_expect_failure 'check a file that was imported twice' '\n+\n+\ttest_cmp_branch_file master imported-twice.txt\n+\n+'\n+\n+test_expect_success 'check a file that was imported then modified on HEAD' '\n+\n+\ttest_cmp_branch_file master imported-modified.txt\n+\n+'\n+\n+test_expect_success 'check a file that was imported, modified, then imported again' '\n+\n+\ttest_cmp_branch_file master imported-modified-imported.txt\n+\n+'\n+\n+test_expect_success 'check a file that was added to HEAD then imported' '\n+\n+\ttest_cmp_branch_file master added-imported.txt\n+\n+'\n+\n+test_expect_success 'a vendor branch whose tag has been removed' '\n+\n+\ttest_cmp_branch_file master imported-anonymously.txt\n+\n+'\n+\n+test_done\ndiff --git a/t/t9601/cvsroot/CVSROOT/.gitignore b/t/t9601/cvsroot/CVSROOT/.gitignore\nnew file mode 100644\nindex 0000000..c375d5b\n--- /dev/null\n+++ b/t/t9601/cvsroot/CVSROOT/.gitignore\n@@ -0,0 +1 @@\n+history\ndiff --git a/t/t9601/cvsroot/module/added-imported.txt,v b/t/t9601/cvsroot/module/added-imported.txt,v\nnew file mode 100644\nindex 0000000..5f83072\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/added-imported.txt,v\n@@ -0,0 +1,44 @@\n+head\t1.1;\n+access;\n+symbols\n+\tvtag-4:1.1.1.1\n+\tvbranchA:1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.1\n+date\t2004.02.09.15.43.15;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.16;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.1\n+log\n+@Add a file to the working copy.\n+@\n+text\n+@Adding this file, before importing it with different contents.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-4).\n+@\n+text\n+@d1 1\n+a1 1\n+This is vtag-4 (on vbranchA) of added-then-imported.txt.\n+@\n+\ndiff --git a/t/t9601/cvsroot/module/imported-anonymously.txt,v b/t/t9601/cvsroot/module/imported-anonymously.txt,v\nnew file mode 100644\nindex 0000000..55e1b0c\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/imported-anonymously.txt,v\n@@ -0,0 +1,42 @@\n+head\t1.1;\n+branch\t1.1.1;\n+access;\n+symbols\n+\tvtag-1:1.1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.1\n+log\n+@Initial revision\n+@\n+text\n+@This is vtag-1 (on vbranchA) of imported-anonymously.txt.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-1).\n+@\n+text\n+@@\n+\n+\ndiff --git a/t/t9601/cvsroot/module/imported-modified-imported.txt,v b/t/t9601/cvsroot/module/imported-modified-imported.txt,v\nnew file mode 100644\nindex 0000000..e5830ae\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/imported-modified-imported.txt,v\n@@ -0,0 +1,76 @@\n+head\t1.2;\n+access;\n+symbols\n+\tvtag-2:1.1.1.2\n+\tvtag-1:1.1.1.1\n+\tvbranchA:1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.2\n+date\t2004.02.09.15.43.14;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t1.1;\n+\n+1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t1.1.1.2;\n+\n+1.1.1.2\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.2\n+log\n+@First regular commit, to imported-modified-imported.txt, on HEAD.\n+@\n+text\n+@This is a modification of imported-modified-imported.txt on HEAD.\n+It should supersede the version from the vendor branch.\n+@\n+\n+\n+1.1\n+log\n+@Initial revision\n+@\n+text\n+@d1 2\n+a2 1\n+This is vtag-1 (on vbranchA) of imported-modified-imported.txt.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-1).\n+@\n+text\n+@@\n+\n+\n+1.1.1.2\n+log\n+@Import (vbranchA, vtag-2).\n+@\n+text\n+@d1 1\n+a1 1\n+This is vtag-2 (on vbranchA) of imported-modified-imported.txt.\n+@\n+\n+\ndiff --git a/t/t9601/cvsroot/module/imported-modified.txt,v b/t/t9601/cvsroot/module/imported-modified.txt,v\nnew file mode 100644\nindex 0000000..bbcfe44\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/imported-modified.txt,v\n@@ -0,0 +1,59 @@\n+head\t1.2;\n+access;\n+symbols\n+\tvtag-1:1.1.1.1\n+\tvbranchA:1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.2\n+date\t2004.02.09.15.43.14;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t1.1;\n+\n+1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.2\n+log\n+@Commit on HEAD.\n+@\n+text\n+@This is a modification of imported-modified.txt on HEAD.\n+It should supersede the version from the vendor branch.\n+@\n+\n+\n+1.1\n+log\n+@Initial revision\n+@\n+text\n+@d1 2\n+a2 1\n+This is vtag-1 (on vbranchA) of imported-modified.txt.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-1).\n+@\n+text\n+@@\n+\n+\ndiff --git a/t/t9601/cvsroot/module/imported-once.txt,v b/t/t9601/cvsroot/module/imported-once.txt,v\nnew file mode 100644\nindex 0000000..c5dd82b\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/imported-once.txt,v\n@@ -0,0 +1,43 @@\n+head\t1.1;\n+branch\t1.1.1;\n+access;\n+symbols\n+\tvtag-1:1.1.1.1\n+\tvbranchA:1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.1\n+log\n+@Initial revision\n+@\n+text\n+@This is vtag-1 (on vbranchA) of imported-once.txt.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-1).\n+@\n+text\n+@@\n+\n+\ndiff --git a/t/t9601/cvsroot/module/imported-twice.txt,v b/t/t9601/cvsroot/module/imported-twice.txt,v\nnew file mode 100644\nindex 0000000..d1f3f1b\n--- /dev/null\n+++ b/t/t9601/cvsroot/module/imported-twice.txt,v\n@@ -0,0 +1,60 @@\n+head\t1.1;\n+branch\t1.1.1;\n+access;\n+symbols\n+\tvtag-2:1.1.1.2\n+\tvtag-1:1.1.1.1\n+\tvbranchA:1.1.1;\n+locks; strict;\n+comment\t@# @;\n+\n+\n+1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches\n+\t1.1.1.1;\n+next\t;\n+\n+1.1.1.1\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t1.1.1.2;\n+\n+1.1.1.2\n+date\t2004.02.09.15.43.13;\tauthor kfogel;\tstate Exp;\n+branches;\n+next\t;\n+\n+\n+desc\n+@@\n+\n+\n+1.1\n+log\n+@Initial revision\n+@\n+text\n+@This is vtag-1 (on vbranchA) of imported-twice.txt.\n+@\n+\n+\n+1.1.1.1\n+log\n+@Import (vbranchA, vtag-1).\n+@\n+text\n+@@\n+\n+\n+1.1.1.2\n+log\n+@Import (vbranchA, vtag-2).\n+@\n+text\n+@d1 1\n+a1 1\n+This is vtag-2 (on vbranchA) of imported-twice.txt.\n+@\n+\n+\ndiff --git a/t/t96xx/cvs-lib.sh b/t/t96xx/cvs-lib.sh\nindex 0136b36..785d8d6 100644\n--- a/t/t96xx/cvs-lib.sh\n+++ b/t/t96xx/cvs-lib.sh\n@@ -48,6 +48,12 @@ test_git_co_branch () {\n \t(cd module-git && git checkout \"$1\")\n }\n \n+test_cmp_branch_file () {\n+\t# Usage: test_cmp_branch_file BRANCH_NAME PATH\n+\t# The branch must already be checked out of CVS and git.\n+\ttest_cmp module-cvs-\"$1\"/\"$2\" module-git/\"$2\"\n+}\n+\n test_cmp_branch_tree () {\n \t# Usage: test_cmp_branch_tree BRANCH_NAME\n \t# Check BRANCH_NAME out of CVS and git and make sure that all\n-- \n1.6.1.3\n"},{"id":"105568","messageId":"20090220062543.GA27837@coredump.intra.peff.net","threadId":"17912","inReplyTo":"1235107093-32605-1-git-send-email-mhagger@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-20T06:25:43Z","receivedAt":"2009-02-20T06:25:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2009 at 06:18:09AM +0100, Michael Haggerty wrote:\n\n> The test suite for \"git cvsimport\" is pretty limited, and I would like\n> to improve the situation. This patch series contains the first of\n> what I hope will eventually be several additions to the \"git\n> cvsimport\" test suite.\n\nGreat. I agree the test suite is terrible for cvsimport; what little is\nthere was added only after a regression where it was totally broken. ;)\n\n> I am the maintainer of cvs2svn/cvs2git. Most of the new tests will\n> probably use fragments from the cvs2svn test suite. I should admit\n> that part of my motivation for adding tests to the \"git cvsimport\"\n> test suite is to document its weaknesses, which do not seem to be\n> especially well known.\n\nI don't think it is a problem to document cvsimport's weakness. It is\nclear from list traffic that it has shortcomings, and IMHO documenting\nthem clearly and rigorously with test cases is the first step to fixing\nthem (or admitting that people should just use something else ;) ).\n\nThe only downside I see is that it bloats git's test suite a bit (and\ncvs tests are often slow to run). We can always make them optional,\nI suppose.\n\nI do wonder, though, whether it would be simpler to make a \"cvs import\ntest suite\" that could pluggably test cvs2svn, git-cvsimport, or other\nconverters. Then you could test each on the exact same set of test\nrepos. And abstracting \"OK, now make a repository from this cvsroot\"\nwouldn't be that hard for each command (I wouldn't think, but obviously\nI haven't tried it :) ).\n\n> Patch 1 splits out some code into a library usable by multiple\n> CVS-related tests.\n\nThat is definitely a good first step, though the usual naming convention\nis t/lib-cvs.sh. See t/lib-{git-svn,httpd,rebase}.sh, for example.\n\n> Patch 2 changes the library to add the -f option when invoking cvs (to\n> make it ignore the user's ~/.cvsrc file).\n\nThe code in t9600 (which gets moved to lib-cvs in your patch 1) sets\nHOME explicitly. So is this really a problem?\n\n> Patch 3 adds a new test to t9600, namely to compare the entire module\n> as checked out by CVS vs. git.\n\nSounds reasonable.\n\n> Patch 4 adds a new test script t9601 that tests \"git cvsimport\"'s\n> handling of CVS vendor branches. One of these tests fails due to an\n> actual bug.\n\nCool. Are you volunteering to fix git-cvsimport, too? :)\n\n> The second is that the new test script uses a small CVS repository\n> that is part of the test suite (i.e., the *,v files are committed\n> directly into the git source tree). This is different than the\n> approach of t9600, which creates its own test CVS repository using CVS\n> commands. The reasons for this are:\n\nI think that's fine. There are other places in the test suite where\nthings that are a pain to produce are just included as content (e.g.,\nsee some of the SVN tests in the 9100 series).\n\nAnd I think all of the reasons you gave are compelling.\n\n> Finally, the *,v files comprising the CVS repository have blank\n> trailing lines, triggering a warning from \"git diff --check\". I don't\n> think that CVS strictly requires the blank lines, but they are always\n> generated by CVS, so I left them in. But if the \"git diff --check\"\n> warnings are considered a serious problem, the blank lines could\n> probably be removed.\n\nIt's best to leave them in, I think, to create as realistic a test as\npossible. But you should mark the paths as \"we don't care about\nwhitespace\" using gitattributes. I.e.,:\n\ndiff --git a/t/t9601/.gitattributes b/t/t9601/.gitattributes\nnew file mode 100644\nindex 0000000..562b12e\n--- /dev/null\n+++ b/t/t9601/.gitattributes\n@@ -0,0 +1 @@\n+* -whitespace\n\n-Peff\n"},{"id":"105572","messageId":"7vzlghftdj.fsf@gitster.siamese.dyndns.org","threadId":"17912","inReplyTo":"20090220062543.GA27837@coredump.intra.peff.net","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-20T07:40:56Z","receivedAt":"2009-02-20T07:40:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\nThanks for a review. Everything you said makes sense to me.\n\nAlso I noticed that [3/4] uses \"diff -r -x\" --- does it pretty much mean\nwe require GNU diff to pass the test? Can this be made more portable?\n"},{"id":"105579","messageId":"56112.77.61.241.211.1235118428.squirrel@hupie.xs4all.nl","threadId":"17912","inReplyTo":"1235107093-32605-1-git-send-email-mhagger@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Ferry Huberts (Pelagic)","fromEmail":"ferry.huberts@pelagic.nl","sentAt":"2009-02-20T08:27:08Z","receivedAt":"2009-02-20T08:27:08Z","isPatch":true,"sender":{"key":"ferry.huberts@pelagic.nl","avatar":"https://gravatar.com/avatar/9f63c0289ad23cbdef0f7609a0af85ff0f4b3babfd066de9ff58f62d48cfd6f2?d=mp&s=160"},"body":" Hi,\n\n I'm actually working on coming up with a patch for a bug I hit that has to to do with safecrlf=true. Maybe now I should coordinate with you?\n\n See this thread\n http://article.gmane.org/gmane.comp.version-control.git/110152\n\n Ferry\n\n Michael Haggerty wrote: The test suite for \"git cvsimport\" is pretty limited, and I would like to improve the situation. This patch series contains the first of what I hope will eventually be\nseveral additions to the \"git cvsimport\" test suite. I am the maintainer of cvs2svn/cvs2git. Most of the new tests will probably use fragments from the cvs2svn test suite. I should admit that\npart of my motivation for adding tests to the \"git cvsimport\" test suite is to document its weaknesses, which do not seem to be especially well known. Patch 1 splits out some code into a library\nusable by multiple CVS-related tests. Patch 2 changes the library to add the -f option when invoking cvs (to make it ignore the user's ~/.cvsrc file). Patch 3 adds a new test to t9600, namely to\ncompare the entire module as checked out by CVS vs. git. Patch 4 adds a new test script t9601 that tests \"git cvsimport\"'s handling of CVS vendor branches. One of these tests fails due to an\nactual bug. These ideas in the patches are logically independent of each other, but each patch assumes that the previous patches have been applied. I would like to point out a few things about\nthese patches that seem a little bit unprecedented in the git test suite. If other approaches would be preferred, please let me know. The first is that I would like to introduce a library that can\nbe used by the \"git cvsimport\" tests in the t96xx series, simply to avoid code duplication. I put this library in t/t96xx/cvs-lib.sh, to hopefully make its role clear. The library has to be\nsourced from the main test directory. (It sources test-lib.sh indirectly.) The second is that the new test script uses a small CVS repository that is part of the test suite (i.e., the *,v files\nare committed directly into the git source tree). This is different than the approach of t9600, which creates its own test CVS repository using CVS commands. The reasons for this are: - t9600\nwants to test incremental import, so it *has to* create the repository dynamically. That is not the case for t9601, which only tests a one-shot import. - The repository for t9601 is derived\nfrom one that already exists as part of the cvs2svn test suite. Reverse-engineering it into CVS commands would be extra work. - The code to create CVS repositories via CVS commands is not very\n illuminating, and runs slowly, as CVS throttles commits to 1 per second (to ensure unique timestamps). - Future tests may require even more complicated CVS repositories that are even more\ncumbersome to create, so it's good to set a precedent now :-) Finally, the *,v files comprising the CVS repository have blank trailing lines, triggering a warning from \"git diff --check\". I\ndon't think that CVS strictly requires the blank lines, but they are always generated by CVS, so I left them in. But if the \"git diff --check\" warnings are considered a serious problem, the blank\nlines could probably be removed. Cheers, Michael -- To unsubscribe from this list: send the line \"unsubscribe git\" in the body of a message to majordomo@vger.kernel.org More majordomo info at \nhttp://vger.kernel.org/majordomo-info.html\n"},{"id":"105598","messageId":"499E8432.9010806@alum.mit.edu","threadId":"17912","inReplyTo":"20090220062543.GA27837@coredump.intra.peff.net","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T10:21:38Z","receivedAt":"2009-02-20T10:21:38Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Jeff King wrote:\n> On Fri, Feb 20, 2009 at 06:18:09AM +0100, Michael Haggerty wrote:\n> [...]\n> I do wonder, though, whether it would be simpler to make a \"cvs import\n> test suite\" that could pluggably test cvs2svn, git-cvsimport, or other\n> converters. Then you could test each on the exact same set of test\n> repos. And abstracting \"OK, now make a repository from this cvsroot\"\n> wouldn't be that hard for each command (I wouldn't think, but obviously\n> I haven't tried it :) ).\n\nMany tests only need to compare the contents of branches/tags checked\nout of CVS with those checked out of the converted repository. Such\ntests could pretty easily be made agnostic about what conversion tool\nthey are testing and also, for that matter, the type of the target VCS\n(git, SVN, hg, ...). Testing incremental conversions at that level of\ndetail would not be much harder.\n\nBut other tests would be harder to write in a neutral fashion. For\nexample, the cvs2svn test suite has tests of log messages, character-set\nconversions of metadata, correct commit ordering, branching topology, etc.\n\nIn fact, one of the many things I haven't gotten around to yet is\nwriting a nontrivial test suite for cvs2git. I'd like to share as much\nas possible with the cvs2svn test suite, but there is a lot there that\nis SVN-specific.\n\n>> Patch 1 splits out some code into a library usable by multiple\n>> CVS-related tests.\n> \n> That is definitely a good first step, though the usual naming convention\n> is t/lib-cvs.sh. See t/lib-{git-svn,httpd,rebase}.sh, for example.\n\nThanks, I hadn't noticed that. I'll change it the v2 of the patch.\n\n>> Patch 2 changes the library to add the -f option when invoking cvs (to\n>> make it ignore the user's ~/.cvsrc file).\n> \n> The code in t9600 (which gets moved to lib-cvs in your patch 1) sets\n> HOME explicitly. So is this really a problem?\n\nThat's a good question. I just checked, and empirically cvs uses .cvsrc\nfrom my true home directory even if HOME is set differently. So I think\nthat the -f option is indeed necessary.\n\n>> Patch 4 adds a new test script t9601 that tests \"git cvsimport\"'s\n>> handling of CVS vendor branches. One of these tests fails due to an\n>> actual bug.\n> \n> Cool. Are you volunteering to fix git-cvsimport, too? :)\n\nNot unless you call cvs2git the fixed version :-)\n\n>> Finally, the *,v files comprising the CVS repository have blank\n>> trailing lines, triggering a warning from \"git diff --check\". I don't\n>> think that CVS strictly requires the blank lines, but they are always\n>> generated by CVS, so I left them in. But if the \"git diff --check\"\n>> warnings are considered a serious problem, the blank lines could\n>> probably be removed.\n> \n> It's best to leave them in, I think, to create as realistic a test as\n> possible. But you should mark the paths as \"we don't care about\n> whitespace\" using gitattributes. I.e.,:\n> \n> diff --git a/t/t9601/.gitattributes b/t/t9601/.gitattributes\n> new file mode 100644\n> index 0000000..562b12e\n> --- /dev/null\n> +++ b/t/t9601/.gitattributes\n> @@ -0,0 +1 @@\n> +* -whitespace\n\nCool, I didn't know about that feature. I'll include that in v2 as well.\n\nThanks for the feedback!\n\nBTW, I don't want to trash \"git cvsimport\". I'm not brave enough even\nto try to implement incremental conversions in cvs2git. So the fact\nthat cvsimport sometimes works is already impressive :-) I also\nunderstand that its limitations come from those of cvsps, another\nimpressive but flawed tool (which in turn is being used outside of its\ndesign limits). But I hope to raise awareness that cvsps-based tools\nare not the best choice for \"one-shot\" conversions, and maybe work\nagainst people's tendency to use the \"default\" tool unless it obviously\nblows up.\n\nMichael\n"},{"id":"105601","messageId":"499E92FD.8000900@alum.mit.edu","threadId":"17912","inReplyTo":"7vzlghftdj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-20T11:24:45Z","receivedAt":"2009-02-20T11:24:45Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Junio C Hamano wrote:\n> Also I noticed that [3/4] uses \"diff -r -x\" --- does it pretty much mean\n> we require GNU diff to pass the test? Can this be made more portable?\n\nI can't think offhand of a more portable tool that could replace \"diff\n-r -x\" here (suggestions, anyone?). Of course one could re-implement\nrecursive diff in shell or perl, and I will take a stab at it if you\nconsider it important. Alternatively, one could hardcode the paths that\nthe test scripts should test, but that would cost more per-test work\nthat I'd rather avoid.\n\nMichael\n"},{"id":"105610","messageId":"cf17659db8a4f7fe9d878984effcdd8d6417c862.1235138849u.git.johannes.schindelin@gmx.de","threadId":"17912","inReplyTo":"499E92FD.8000900@alum.mit.edu","subject":"[HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-20T14:12:28Z","receivedAt":"2009-02-20T14:12:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"With this patch, it is possible to exclude files based on basename\npatterns. Example:\n\n\t$ git diff --no-index -x Makefile -x Makefile.in a/ b/\n\nIn this example, the recursive diff between a/ and b/ will be shown\nmodulo changes in files named 'Makefile' or 'Makefile.in'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tMichael wrote:\n\n\t> I can't think offhand of a more portable tool that could replace \n\t> \"diff -r -x\" here (suggestions, anyone?).\n\n\tMaybe something like this?\n\n\tNote: before it can be included in git.git, documentation and \n\ttests have to be added; also, it might be a good idea to extend it \n\tto the \"non-no-index\" case (maybe I can beat Peff in the number of \n\tdouble negations one day...)\n\n\tSo why only half a patch? From time to time, I have to remember \n\tthat I work on Git for fun. And this was the fun part, as far as \n\tI am concerned.\n\n diff-no-index.c | 50 ++++++++++++++++++++++++++++++++++++++++++++------\n diff.c | 9 +++++++++\n diff.h | 6 ++++++\n 3 files changed, 59 insertions(+), 6 deletions(-)\n\ndiff --git a/diff-no-index.c b/diff-no-index.c\nindex 0a14268..0dc924a 100644\n--- a/diff-no-index.c\n+++ b/diff-no-index.c\n@@ -16,7 +16,42 @@\n #include \"builtin.h\"\n #include \"string-list.h\"\n \n-static int read_directory(const char *path, struct string_list *list)\n+void add_basename_exclude(const char *exclude, struct diff_options *opts)\n+{\n+\tif (!opts->basename_excludes) {\n+\t\topts->basename_excludes =\n+\t\t\txcalloc(sizeof(struct string_list), 1);\n+\t\topts->basename_excludes->strdup_strings = 1;\n+\t}\n+\n+\tstring_list_append(exclude, opts->basename_excludes);\n+}\n+\n+int basename_is_excluded(const char *basename, struct diff_options *options)\n+{\n+\tint i;\n+\n+\tif (!options->basename_excludes)\n+\t\treturn 0;\n+\n+\tfor (i = 0; i < options->basename_excludes->nr; i++)\n+\t\tif (!fnmatch(options->basename_excludes->items[i].string,\n+\t\t\t\t\tbasename, 0))\n+\t\t\treturn 1;\n+\treturn 0;\n+}\n+\n+void free_basename_excludes(struct diff_options *options)\n+{\n+\tif (!options->basename_excludes)\n+\t\treturn;\n+\tstring_list_clear(options->basename_excludes, 0);\n+\tfree(options->basename_excludes);\n+\toptions->basename_excludes = NULL;\n+}\n+\n+static int read_directory(const char *path, struct string_list *list,\n+\tstruct diff_options *options)\n {\n \tDIR *dir;\n \tstruct dirent *e;\n@@ -25,7 +60,8 @@ static int read_directory(const char *path, struct string_list *list)\n \t\treturn error(\"Could not open directory %s\", path);\n \n \twhile ((e = readdir(dir)))\n-\t\tif (strcmp(\".\", e->d_name) && strcmp(\"..\", e->d_name))\n+\t\tif (strcmp(\".\", e->d_name) && strcmp(\"..\", e->d_name) &&\n+\t\t\t\t!basename_is_excluded(e->d_name, options))\n \t\t\tstring_list_insert(e->d_name, list);\n \n \tclosedir(dir);\n@@ -63,9 +99,9 @@ static int queue_diff(struct diff_options *o,\n \t\tstruct string_list p1 = {NULL, 0, 0, 1}, p2 = {NULL, 0, 0, 1};\n \t\tint len1 = 0, len2 = 0, i1, i2, ret = 0;\n \n-\t\tif (name1 && read_directory(name1, &p1))\n+\t\tif (name1 && read_directory(name1, &p1, o))\n \t\t\treturn -1;\n-\t\tif (name2 && read_directory(name2, &p2)) {\n+\t\tif (name2 && read_directory(name2, &p2, o)) {\n \t\t\tstring_list_clear(&p1, 0);\n \t\t\treturn -1;\n \t\t}\n@@ -177,10 +213,12 @@ void diff_no_index(struct rev_info *revs,\n \t\t\ti++;\n \t\t\tbreak;\n \t\t}\n-\t\tif (!strcmp(argv[i], \"--no-index\"))\n-\t\t\tno_index = 1;\n \t\tif (argv[i][0] != '-')\n \t\t\tbreak;\n+\t\tif (!strcmp(argv[i], \"--no-index\"))\n+\t\t\tno_index = 1;\n+\t\telse if (!strcmp(argv[i], \"-x\"))\n+\t\t\ti++;\n \t}\n \n \tif (!no_index && !nongit) {\ndiff --git a/diff.c b/diff.c\nindex 55d73a1..29c0dd5 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -2653,6 +2653,14 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)\n \telse if (!prefixcmp(arg, \"--output=\")) {\n \t\toptions->file = fopen(arg + strlen(\"--output=\"), \"w\");\n \t\toptions->close_file = 1;\n+\t}\n+\telse if (!prefixcmp(arg, \"--exclude=\"))\n+\t\tadd_basename_exclude( arg + strlen(\"--exclude=\"), options);\n+\telse if (!strcmp(arg, \"-x\")) {\n+\t\tif (ac < 2)\n+\t\t\tdie (\"-x needs a parameter\");\n+\t\tadd_basename_exclude(av[1], options);\n+\t\treturn 2;\n \t} else\n \t\treturn 0;\n \treturn 1;\n@@ -3306,6 +3314,7 @@ free_queue:\n \tq->nr = q->alloc = 0;\n \tif (options->close_file)\n \t\tfclose(options->file);\n+\tfree_basename_excludes(options);\n }\n \n static void diffcore_apply_filter(const char *filter)\ndiff --git a/diff.h b/diff.h\nindex 6703a4f..38f3acd 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -113,6 +113,7 @@ struct diff_options {\n \tadd_remove_fn_t add_remove;\n \tdiff_format_fn_t format_callback;\n \tvoid *format_callback_data;\n+\tstruct string_list *basename_excludes;\n };\n \n enum color_diff {\n@@ -267,4 +268,9 @@ extern void diff_no_index(struct rev_info *, int, const char **, int, const char\n \n extern int index_differs_from(const char *def, int diff_flags);\n \n+extern int basename_is_excluded(const char *path, struct diff_options *options);\n+extern void add_basename_exclude(const char *exclude,\n+\t\tstruct diff_options *options);\n+extern void free_basename_excludes(struct diff_options *options);\n+\n #endif /* DIFF_H */\n-- \n1.6.2.rc1.350.g6caf6\n"},{"id":"105614","messageId":"20090220145331.GA3515@coredump.intra.peff.net","threadId":"17912","inReplyTo":"cf17659db8a4f7fe9d878984effcdd8d6417c862.1235138849u.git.johannes.schindelin@gmx.de","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-20T14:53:31Z","receivedAt":"2009-02-20T14:53:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2009 at 03:12:28PM +0100, Johannes Schindelin wrote:\n\n> \tMichael wrote:\n> \n> \t> I can't think offhand of a more portable tool that could replace \n> \t> \"diff -r -x\" here (suggestions, anyone?).\n> \n> \tMaybe something like this?\n\nGreat. Using \"git diff\" was my first thought, too.\n\n> \tNote: before it can be included in git.git, documentation and \n> \ttests have to be added; also, it might be a good idea to extend it \n> \tto the \"non-no-index\" case (maybe I can beat Peff in the number of \n> \tdouble negations one day...)\n\nMaybe a config option \"diff.denyNonIndexExclude = false\"? *ducks*\n\nBut more seriously, how would a user expect this to interact with\n.gitignore? I know gitignore is about ignoring untracked files, but I\ncan't help but feel the two have something in common. But maybe not. I'm\nsick today and my brain is not working very well.\n\n-Peff\n"},{"id":"105616","messageId":"20090220150022.GB3515@coredump.intra.peff.net","threadId":"17912","inReplyTo":"499E8432.9010806@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-20T15:00:22Z","receivedAt":"2009-02-20T15:00:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2009 at 11:21:38AM +0100, Michael Haggerty wrote:\n\n> > I do wonder, though, whether it would be simpler to make a \"cvs import\n> > test suite\" that could pluggably test cvs2svn, git-cvsimport, or other\n> > converters. Then you could test each on the exact same set of test\n> > repos. And abstracting \"OK, now make a repository from this cvsroot\"\n> > wouldn't be that hard for each command (I wouldn't think, but obviously\n> > I haven't tried it :) ).\n> [...]\n> But other tests would be harder to write in a neutral fashion. For\n> example, the cvs2svn test suite has tests of log messages, character-set\n> conversions of metadata, correct commit ordering, branching topology, etc.\n\nOK. I haven't looked at it and you have, so I will accept your\njudgement.\n\n> > The code in t9600 (which gets moved to lib-cvs in your patch 1) sets\n> > HOME explicitly. So is this really a problem?\n> \n> That's a good question. I just checked, and empirically cvs uses .cvsrc\n> from my true home directory even if HOME is set differently. So I think\n> that the -f option is indeed necessary.\n\nYuck. But if that's the way it works, then I think your patch is the\nonly way.\n\n> > Cool. Are you volunteering to fix git-cvsimport, too? :)\n> Not unless you call cvs2git the fixed version :-)\n\nHeh.\n\n> design limits). But I hope to raise awareness that cvsps-based tools\n> are not the best choice for \"one-shot\" conversions, and maybe work\n> against people's tendency to use the \"default\" tool unless it obviously\n> blows up.\n\nAgreed. I have seen that advice given on the list several times, and it\nseems to be working for people. So it really is about the right tool for\nthe job, IMHO.\n\n-Peff\n"},{"id":"105617","messageId":"alpine.DEB.1.00.0902201555490.6302@intel-tinevez-2-302","threadId":"17912","inReplyTo":"20090220145331.GA3515@coredump.intra.peff.net","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-20T15:03:25Z","receivedAt":"2009-02-20T15:03:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Feb 2009, Jeff King wrote:\n\n> On Fri, Feb 20, 2009 at 03:12:28PM +0100, Johannes Schindelin wrote:\n> \n> > \tMichael wrote:\n> > \n> > \t> I can't think offhand of a more portable tool that could replace \n> > \t> \"diff -r -x\" here (suggestions, anyone?).\n> > \n> > \tMaybe something like this?\n> \n> Great. Using \"git diff\" was my first thought, too.\n\nHeh :-)\n\nI have to admit that I had something pretty ugly involving find and grep \nin mind at first, then something equally appalling using GIT_WORKTREE and \nGIT_INDEX_FILE.\n\n> > \tNote: before it can be included in git.git, documentation and \n> > \ttests have to be added; also, it might be a good idea to extend it \n> > \tto the \"non-no-index\" case (maybe I can beat Peff in the number of \n> > \tdouble negations one day...)\n> \n> Maybe a config option \"diff.denyNonIndexExclude = false\"? *ducks*\n\nHow about diffNoIndex.denyNonIndexNonExclude = !true? *swans*\n\n> But more seriously, how would a user expect this to interact with \n> .gitignore? I know gitignore is about ignoring untracked files, but I \n> can't help but feel the two have something in common. But maybe not. I'm \n> sick today and my brain is not working very well.\n\nI think that the -x option with regular (not --no-index) diff would be \na little different. .gitignore is for \"git add\" time, while \"git diff\" \nhappily ignores .gitignore.\n\nBesides, the -x option only works on the basenames (as I implemented it; \nno idea if GNU diff works the same way, but from Michael's patch it looks \nlike it does).\n\nBTW I just realized that I forgot to add a die() when !no_index && \nbasename_excludes.\n\nCiao,\nDscho\n"},{"id":"105623","messageId":"7v1vttt6d4.fsf@gitster.siamese.dyndns.org","threadId":"17912","inReplyTo":"cf17659db8a4f7fe9d878984effcdd8d6417c862.1235138849u.git.johannes.schindelin@gmx.de","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-20T16:34:15Z","receivedAt":"2009-02-20T16:34:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> With this patch, it is possible to exclude files based on basename\n> patterns. Example:\n>\n> \t$ git diff --no-index -x Makefile -x Makefile.in a/ b/\n>\n> In this example, the recursive diff between a/ and b/ will be shown\n> modulo changes in files named 'Makefile' or 'Makefile.in'.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> \tMichael wrote:\n>\n> \t> I can't think offhand of a more portable tool that could replace \n> \t> \"diff -r -x\" here (suggestions, anyone?).\n>\n> \tMaybe something like this?\n\nI agree that diff_options is the logical way to hook this information and\ndiff_opt_parse() is the right place to add this, but why isn't this done\nat diff_{addremove,change,unmerge}() layer? That way you should be able\nto cover both no-index special case and the normal diffs, no?\n"},{"id":"105640","messageId":"m3skm9rm6h.fsf@localhost.localdomain","threadId":"17912","inReplyTo":"alpine.DEB.1.00.0902201555490.6302@intel-tinevez-2-302","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-20T18:34:30Z","receivedAt":"2009-02-20T18:34:30Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin writes:\n> On Fri, 20 Feb 2009, Jeff King wrote:\n> \n> > But more seriously, how would a user expect this to interact with \n> > .gitignore? I know gitignore is about ignoring untracked files, but I \n> > can't help but feel the two have something in common. But maybe not. I'm \n> > sick today and my brain is not working very well.\n> \n> I think that the -x option with regular (not --no-index) diff would be \n> a little different. .gitignore is for \"git add\" time, while \"git diff\" \n> happily ignores .gitignore.\n> \n> Besides, the -x option only works on the basenames (as I implemented it; \n> no idea if GNU diff works the same way, but from Michael's patch it looks \n> like it does).\n\nInfo: (diff.info.gz)diff Options\n\n`-x PATTERN'\n`--exclude=PATTERN'\n When comparing directories, ignore files and subdirectories whose\n basenames match PATTERN. *Note Comparing Directories::.\n\n`-X FILE'\n`--exclude-from=FILE'\n When comparing directories, ignore files and subdirectories whose\n basenames match any pattern contained in FILE. *Note Comparing\n Directories::.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"105648","messageId":"alpine.DEB.1.00.0902202104120.6302@intel-tinevez-2-302","threadId":"17912","inReplyTo":"m3skm9rm6h.fsf@localhost.localdomain","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-20T20:04:27Z","receivedAt":"2009-02-20T20:04:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Feb 2009, Jakub Narebski wrote:\n\n> Johannes Schindelin writes:\n> > On Fri, 20 Feb 2009, Jeff King wrote:\n> > \n> > > But more seriously, how would a user expect this to interact with \n> > > .gitignore? I know gitignore is about ignoring untracked files, but I \n> > > can't help but feel the two have something in common. But maybe not. I'm \n> > > sick today and my brain is not working very well.\n> > \n> > I think that the -x option with regular (not --no-index) diff would be \n> > a little different. .gitignore is for \"git add\" time, while \"git diff\" \n> > happily ignores .gitignore.\n> > \n> > Besides, the -x option only works on the basenames (as I implemented it; \n> > no idea if GNU diff works the same way, but from Michael's patch it looks \n> > like it does).\n> \n> Info: (diff.info.gz)diff Options\n> \n> `-x PATTERN'\n> `--exclude=PATTERN'\n> When comparing directories, ignore files and subdirectories whose\n> basenames match PATTERN. *Note Comparing Directories::.\n\nThanks for the clarification!\n\nCiao,\nDscho\n"},{"id":"105654","messageId":"499F201E.2050106@datacom.ind.br","threadId":"17912","inReplyTo":"499E8432.9010806@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Samuel Lucas Vaz de Mello","fromEmail":"samuellucas@datacom.ind.br","sentAt":"2009-02-20T21:26:54Z","receivedAt":"2009-02-20T21:26:54Z","isPatch":true,"sender":{"key":"samuellucas@datacom.ind.br","avatar":null},"body":"Michael Haggerty wrote:\n> BTW, I don't want to trash \"git cvsimport\". I'm not brave enough even\n> to try to implement incremental conversions in cvs2git. So the fact\n\nMichael,\n\nIf I run cvs2git several times against a live cvs repo (using the same configuration), wouldn't it perform an incremental import?\nIs there anything that would make it produce different commits for the history?\n\nI've just made a simple test here performing 2 imports (the 2nd with a dozen of new commits not in the 1st) and it seemed to work fine.\n\nI know that it will take the same time/memory as the first import, but is there something that can break the repository or produce wrong data?\n\nThanks,\n\n - Samuel\n"},{"id":"105692","messageId":"499F9FE9.6050006@alum.mit.edu","threadId":"17912","inReplyTo":"499F201E.2050106@datacom.ind.br","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-21T06:32:09Z","receivedAt":"2009-02-21T06:32:09Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Samuel Lucas Vaz de Mello wrote:\n> Michael Haggerty wrote:\n>> BTW, I don't want to trash \"git cvsimport\". I'm not brave enough even\n>> to try to implement incremental conversions in cvs2git. So the fact\n> \n> If I run cvs2git several times against a live cvs repo (using the\n> same configuration), wouldn't it perform an incremental import?\n> Is there anything that would make it produce different commits for\n> the history?\n> \n> I've just made a simple test here performing 2 imports (the 2nd with a\n> dozen of new commits not in the 1st) and it seemed to work fine.\n> \n> I know that it will take the same time/memory as the first import,\n> but is there something that can break the repository or produce wrong\n> data?\n\nCool, I'd never thought of that. It's certainly not by design, but as\nyou've discovered, the interaction of cvs2git and git *almost* combine\nto give you an incremental import.\n\nAlas, it is only \"almost\". There are many things that can happen in a\nCVS repository that would cause the overlapping part of the history to\ndisagree between runs of cvs2svn. The nastiest are things that a VCS\nshouldn't really even allow, but are common in CVS, like\n\n- Retroactively adding a file to a branch or tag. (This is a\nmuch-beloved feature of CVS.) Since CVS doesn't record the timestamp\nwhen a symbol is added to a file, cvs2git tries (subject to the\nconstraints of other timestamps) to group all such changes into a single\nchangeset. So the creation of the symbol would look different in runs N\nvs N+1 of cvs2git--containing different files and likely with a\ndifferent timestamp.\n\n- Renaming a file \"with history\" by renaming or copying the associated\n*,v file in the repository. This retroactively changes the entire\nhistory of that file and thus of all changesets that involved changes to\nthat file.\n\n- Changing the \"text vs binary\" or keyword expansion mode of a file.\nThese properties apply to all revisions of a file, and therefore also\nhave a retroactive effect.\n\nBut even aside from these retroactive changes, the output of cvs2git is\nnot deterministic in any practical sense (though I've tried to make it\ndeterministic given *identical* input). The problem is that there are\nso many ambiguities in a CVS history (because CVS doesn't record enough\ninformation) that cvs2git has to use heuristics to decide what\nindividual file events should be grouped together as commits. The\ntrickiest part is that the graph of naively inferred changesets can have\ncycles in it, and cvs2git uses several heuristics to decide how to split\nup changesets so as to remove the cycles. (See our design notes [1] for\nall the hairy details.) The CVS commits made between runs N and N+1\ncould easily change some of the heuristics' decisions, giving different\nresults even for the overlapping part of the history.\n\nTo add robust support for incremental commits to cvs2git would require\nrun N+1 to know about the decisions made in run N, to avoid\ncontradicting them.\n\nI wonder what would happen if one would treat the results of cvs2git\nconversions N and N+1 as two separate repositories and merge them using\ngit. In many cases the merge would probably be trivial, and most\nconflicts (except retroactive file renaming!) would probably tend to be\nin the recent past and therefore resolvable manually. At least the\nrepository shouldn't silently become corrupted, which can happen with\nother incremental conversion tools.\n\nThe final problem is that cvs2git conversions of large CVS repositories\nare quite time-consuming, so using it for incremental conversions of\nlarge repositories would be painful. No doubt it could be speeded up\nconsiderably, especially if conversion N+1 was privy to the results of\nconversion N.\n\nThese are all challenging problems and I would welcome volunteers and be\nhappy to get them started.\n\nMichael\n\n[1] http://cvs2svn.tigris.org/svn/cvs2svn/trunk/doc/design-notes.txt\n"},{"id":"105714","messageId":"499FFC1C.5080801@alum.mit.edu","threadId":"17912","inReplyTo":"56112.77.61.241.211.1235118428.squirrel@hupie.xs4all.nl","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-02-21T13:05:32Z","receivedAt":"2009-02-21T13:05:32Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Ferry Huberts (Pelagic) wrote:\n> I'm actually working on coming up with a patch for a bug I hit that\n> has to to do with safecrlf=true. Maybe now I should coordinate with you?\n\nI am only adding some tests of \"git cvsimport\"; I definitely don't plan\nto become a \"git cvsimport\" hacker. But we can certainly work together\non the test infrastructure if it will help you.\n\nMichael\n"},{"id":"105715","messageId":"499FFF44.9080205@pelagic.nl","threadId":"17912","inReplyTo":"499FFC1C.5080801@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Ferry Huberts (Pelagic)","fromEmail":"ferry.huberts@pelagic.nl","sentAt":"2009-02-21T13:19:00Z","receivedAt":"2009-02-21T13:19:00Z","isPatch":true,"sender":{"key":"ferry.huberts@pelagic.nl","avatar":"https://gravatar.com/avatar/9f63c0289ad23cbdef0f7609a0af85ff0f4b3babfd066de9ff58f62d48cfd6f2?d=mp&s=160"},"body":"Michael Haggerty wrote:\n> Ferry Huberts (Pelagic) wrote:\n> \n>> I'm actually working on coming up with a patch for a bug I hit that\n>> has to to do with safecrlf=true. Maybe now I should coordinate with you?\n>> \n>\n> I am only adding some tests of \"git cvsimport\"; I definitely don't plan\n> to become a \"git cvsimport\" hacker. But we can certainly work together\n> on the test infrastructure if it will help you.\n>\n> Michael\n> \nI'd like to add a couple of tests to t9600 (as per Johannes' suggestion) \nto test my patch\n\nFerry\n"},{"id":"105778","messageId":"7vbpsu2z9b.fsf@gitster.siamese.dyndns.org","threadId":"17912","inReplyTo":"499FFC1C.5080801@alum.mit.edu","subject":"Re: [PATCH 0/4] Add more tests of cvsimport","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-22T16:49:04Z","receivedAt":"2009-02-22T16:49:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> Ferry Huberts (Pelagic) wrote:\n>> I'm actually working on coming up with a patch for a bug I hit that\n>> has to to do with safecrlf=true. Maybe now I should coordinate with you?\n>\n> I am only adding some tests of \"git cvsimport\"; I definitely don't plan\n> to become a \"git cvsimport\" hacker. But we can certainly work together\n> on the test infrastructure if it will help you.\n\nThanks, both. I generally am not very fond of adding tests without\nintention to look into fixes, but if they make outstanding bugs more\nvisible, they may have the effect of shaming the original authors badly\nenough to step in in the effort of fixing them ;-)\n"},{"id":"106072","messageId":"alpine.DEB.1.00.0902241713520.10279@pacific.mpi-cbg.de","threadId":"17912","inReplyTo":"7v1vttt6d4.fsf@gitster.siamese.dyndns.org","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-24T16:15:13Z","receivedAt":"2009-02-24T16:15:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Feb 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > With this patch, it is possible to exclude files based on basename\n> > patterns. Example:\n> >\n> > \t$ git diff --no-index -x Makefile -x Makefile.in a/ b/\n> >\n> > In this example, the recursive diff between a/ and b/ will be shown\n> > modulo changes in files named 'Makefile' or 'Makefile.in'.\n> >\n> > Signed-off-by: Johannes Schindelin \n> > ---\n> >\n> > \tMichael wrote:\n> >\n> > \t> I can't think offhand of a more portable tool that could replace \n> > \t> \"diff -r -x\" here (suggestions, anyone?).\n> >\n> > \tMaybe something like this?\n> \n> I agree that diff_options is the logical way to hook this information and\n> diff_opt_parse() is the right place to add this, but why isn't this done\n> at diff_{addremove,change,unmerge}() layer? That way you should be able\n> to cover both no-index special case and the normal diffs, no?\n\nThe principal aim of this patch was to support git diff --no-index -x, \nthat is why (and in addition, avoiding unnecessary work when we can \nexclude stuff already early in the code path).\n\nIt is unlikely that I will work on this before next week.\n\nThanks,\nDscho\n"},{"id":"106077","messageId":"7vprh7ixbi.fsf@gitster.siamese.dyndns.org","threadId":"17912","inReplyTo":"alpine.DEB.1.00.0902241713520.10279@pacific.mpi-cbg.de","subject":"Re: [HALF A PATCH] Teach the '--exclude' option to 'diff --no-index'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-24T17:01:05Z","receivedAt":"2009-02-24T17:01:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The principal aim of this patch was to support git diff --no-index -x, \n> that is why (and in addition, avoiding unnecessary work when we can \n> exclude stuff already early in the code path).\n>\n> It is unlikely that I will work on this before next week.\n\nOh, that's something I'd welcome, as I'd like to see people not\nnecessarily hunting for but definitely responding to issues in the soon to\nbe tagged 1.6.2, instead of new features ;-)\n"}]}