{"thread":{"id":"48810","subject":"[PATCH 0/6] Add merge recursive testcases with undetected conflicts","startedAt":"2018-07-01T04:11:31Z","lastAt":"2018-07-11T15:40:16Z","messageCount":14,"participants":["Elijah Newren","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"351465","messageId":"20180701041122.8753-1-newren@gmail.com","threadId":"48810","inReplyTo":null,"subject":"[PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:16Z","receivedAt":"2018-07-01T04:11:31Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"SPOILER ALERT: This series contains answers to the \"fun puzzle\" at\n  https://public-inbox.org/git/CABPp-BFc1OLYKzS5rauOehvEugPc0oGMJp-NMEAmVMW7QR=4Eg@mail.gmail.com/\n\nWhen a merge succeeds, we expect the resulting contents to depend only\nupon the trees and blobs of the branches involved and of their merge\nbase(s).  Unfortunately, there are currently about half a dozen cases\nwhere the contents of a \"successful\" merge depend on the relative\ncommit timestamps of the merge bases.  Document these with testcases.\n\n(This series came out of looking at modifying how file collision\nconflict types are handled, as discussed at [1].  I discovered these\nissues while working on that topic.)\n\n[1] https://public-inbox.org/git/CAPc5daVu8vv9RdGON8JiXEO3ycDVqQ38ySzZc-cpo+AQcAKXjA@mail.gmail.com/\n\nElijah Newren (6):\n  t6036: add a failed conflict detection case with symlink modify/modify\n  t6036: add a failed conflict detection case with symlink add/add\n  t6036: add a failed conflict detection case with submodule\n    modify/modify\n  t6036: add a failed conflict detection case with submodule add/add\n  t6036: add a failed conflict detection case with conflicting types\n  t6036: add a failed conflict detection case: regular files, different\n    modes\n\n t/t6036-recursive-corner-cases.sh | 451 ++++++++++++++++++++++++++++++\n 1 file changed, 451 insertions(+)\n\n-- \n2.18.0.130.gd703bbb5d\n"},{"id":"351466","messageId":"20180701041122.8753-2-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 1/6] t6036: add a failed conflict detection case with symlink modify/modify","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:17Z","receivedAt":"2018-07-01T04:11:36Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 67 +++++++++++++++++++++++++++++++\n 1 file changed, 67 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex b5621303d..4a94fa5ba 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -805,4 +805,71 @@ test_expect_success 'virtual merge base handles rename/rename(1to2)/add-dest' '\n \t)\n '\n \n+#\n+# criss-cross with modify/modify on a symlink:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: simple simlink fickle->lagoon\n+#   Commit B: redirect fickle->disneyland\n+#   Commit C: redirect fickle->home\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious modify/modify conflict for the symlink 'fickle'.  Can\n+# git detect it?\n+\n+test_expect_success 'setup symlink modify/modify' '\n+\ttest_create_repo symlink-modify-modify &&\n+\t(\n+\t\tcd symlink-modify-modify &&\n+\n+\t\ttest_ln_s_add lagoon fickle &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\tgit rm fickle &&\n+\t\ttest_ln_s_add disneyland fickle &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\tgit rm fickle &&\n+\t\ttest_ln_s_add home fickle &&\n+\t\tgit add fickle &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check symlink modify/modify' '\n+\t(\n+\t\tcd symlink-modify-modify &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351467","messageId":"20180701041122.8753-3-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 2/6] t6036: add a failed conflict detection case with symlink add/add","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:18Z","receivedAt":"2018-07-01T04:11:39Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 66 +++++++++++++++++++++++++++++++\n 1 file changed, 66 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex 4a94fa5ba..0ba04d46d 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -872,4 +872,70 @@ test_expect_failure 'check symlink modify/modify' '\n \t)\n '\n \n+#\n+# criss-cross with add/add of a symlink:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: No symlink or path exists yet\n+#   Commit B: set up symlink: fickle->disneyland\n+#   Commit C: set up symlink: fickle->home\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious add/add conflict for the symlink 'fickle'.  Can\n+# git detect it?\n+\n+test_expect_success 'setup symlink add/add' '\n+\ttest_create_repo symlink-add-add &&\n+\t(\n+\t\tcd symlink-add-add &&\n+\n+\t\ttouch ignoreme &&\n+\t\tgit add ignoreme &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\ttest_ln_s_add disneyland fickle &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\ttest_ln_s_add home fickle &&\n+\t\tgit add fickle &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check symlink add/add' '\n+\t(\n+\t\tcd symlink-add-add &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 2 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 2 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351468","messageId":"20180701041122.8753-5-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 4/6] t6036: add a failed conflict detection case with submodule add/add","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:20Z","receivedAt":"2018-07-01T04:11:42Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 88 +++++++++++++++++++++++++++++++\n 1 file changed, 88 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex 0c8f81331..e920c7505 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -1026,4 +1026,92 @@ test_expect_failure 'check submodule modify/modify' '\n \t)\n '\n \n+#\n+# criss-cross with add/add on a submodule:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: nothing of note\n+#   Commit B: introduce submodule repo\n+#   Commit C: introduce submodule repo at different commit\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious add/add conflict for the submodule 'repo'.  Can\n+# git detect it?\n+\n+test_expect_success 'setup submodule add/add' '\n+\ttest_create_repo submodule-add-add &&\n+\t(\n+\t\tcd submodule-add-add &&\n+\n+\t\ttest_create_repo submod &&\n+\t\t(\n+\t\t\tcd submod &&\n+\t\t\ttouch file-A &&\n+\t\t\tgit add file-A &&\n+\t\t\tgit commit -m A &&\n+\t\t\tgit tag A &&\n+\n+\t\t\tgit checkout -b B A &&\n+\t\t\ttouch file-B &&\n+\t\t\tgit add file-B &&\n+\t\t\tgit commit -m B &&\n+\t\t\tgit tag B &&\n+\n+\t\t\tgit checkout -b C A &&\n+\t\t\ttouch file-C &&\n+\t\t\tgit add file-C &&\n+\t\t\tgit commit -m C &&\n+\t\t\tgit tag C\n+\t\t) &&\n+\n+\t\ttouch irrelevant-file &&\n+\t\tgit add irrelevant-file &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\tgit -C submod reset --hard B &&\n+\t\tgit add submod &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\tgit -C submod reset --hard C &&\n+\t\tgit add submod &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check submodule add/add' '\n+\t(\n+\t\tcd submodule-add-add &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 2 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351469","messageId":"20180701041122.8753-4-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 3/6] t6036: add a failed conflict detection case with submodule modify/modify","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:19Z","receivedAt":"2018-07-01T04:11:43Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 88 +++++++++++++++++++++++++++++++\n 1 file changed, 88 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex 0ba04d46d..0c8f81331 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -938,4 +938,92 @@ test_expect_failure 'check symlink add/add' '\n \t)\n '\n \n+#\n+# criss-cross with modify/modify on a submodule:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: simple submodule repo\n+#   Commit B: update repo\n+#   Commit C: update repo differently\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious modify/modify conflict for the submodule 'repo'.  Can\n+# git detect it?\n+\n+test_expect_success 'setup submodule modify/modify' '\n+\ttest_create_repo submodule-modify-modify &&\n+\t(\n+\t\tcd submodule-modify-modify &&\n+\n+\t\ttest_create_repo submod &&\n+\t\t(\n+\t\t\tcd submod &&\n+\t\t\ttouch file-A &&\n+\t\t\tgit add file-A &&\n+\t\t\tgit commit -m A &&\n+\t\t\tgit tag A &&\n+\n+\t\t\tgit checkout -b B A &&\n+\t\t\ttouch file-B &&\n+\t\t\tgit add file-B &&\n+\t\t\tgit commit -m B &&\n+\t\t\tgit tag B &&\n+\n+\t\t\tgit checkout -b C A &&\n+\t\t\ttouch file-C &&\n+\t\t\tgit add file-C &&\n+\t\t\tgit commit -m C &&\n+\t\t\tgit tag C\n+\t\t) &&\n+\n+\t\tgit -C submod reset --hard A &&\n+\t\tgit add submod &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\tgit -C submod reset --hard B &&\n+\t\tgit add submod &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\tgit -C submod reset --hard C &&\n+\t\tgit add submod &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check submodule modify/modify' '\n+\t(\n+\t\tcd submodule-modify-modify &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351470","messageId":"20180701041122.8753-7-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 6/6] t6036: add a failed conflict detection case: regular files, different modes","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:22Z","receivedAt":"2018-07-01T04:11:46Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 67 +++++++++++++++++++++++++++++++\n 1 file changed, 67 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex 8b997d7e5..f8f7b3046 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -1189,4 +1189,71 @@ test_expect_failure 'check conflicting entry types (submodule vs symlink)' '\n \t)\n '\n \n+#\n+# criss-cross with regular files that have conflicting modes:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: nothing of note\n+#   Commit B: introduce file source_me.bash, not executable\n+#   Commit C: introduce file source_me.bash, executable\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious add/add mode conflict.  Can git detect it?\n+\n+test_expect_success 'setup conflicting modes for regular file' '\n+\ttest_create_repo regular-file-mode-conflict &&\n+\t(\n+\t\tcd regular-file-mode-conflict &&\n+\n+\t\ttouch irrelevant-file &&\n+\t\tgit add irrelevant-file &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n+\t\tgit add source_me.bash &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n+\t\tgit add source_me.bash &&\n+\t\ttest_chmod +x source_me.bash &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check conflicting modes for regular file' '\n+\t(\n+\t\tcd regular-file-mode-conflict &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 2 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351471","messageId":"20180701041122.8753-6-newren@gmail.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"[PATCH 5/6] t6036: add a failed conflict detection case with conflicting types","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-01T04:11:21Z","receivedAt":"2018-07-01T04:11:49Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Signed-off-by: Elijah Newren <newren@gmail.com>\n---\n t/t6036-recursive-corner-cases.sh | 75 +++++++++++++++++++++++++++++++\n 1 file changed, 75 insertions(+)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex e920c7505..8b997d7e5 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -1114,4 +1114,79 @@ test_expect_failure 'check submodule add/add' '\n \t)\n '\n \n+#\n+# criss-cross with conflicting entry types:\n+#\n+#      B   D\n+#      o---o\n+#     / \\ / \\\n+#  A o   X   ? F\n+#     \\ / \\ /\n+#      o---o\n+#      C   E\n+#\n+#   Commit A: nothing of note\n+#   Commit B: introduce submodule 'path'\n+#   Commit C: introduce symlink 'path'\n+#   Commit D: merge B&C, resolving in favor of B\n+#   Commit E: merge B&C, resolving in favor of C\n+#\n+# This is an obvious add/add conflict for 'path'.  Can git detect it?\n+\n+test_expect_success 'setup conflicting entry types (submodule vs symlink)' '\n+\ttest_create_repo submodule-symlink-add-add &&\n+\t(\n+\t\tcd submodule-symlink-add-add &&\n+\n+\t\ttest_create_repo path &&\n+\t\t(\n+\t\t\tcd path &&\n+\t\t\ttouch file-B &&\n+\t\t\tgit add file-B &&\n+\t\t\tgit commit -m B &&\n+\t\t\tgit tag B\n+\t\t) &&\n+\n+\t\ttouch irrelevant-file &&\n+\t\tgit add irrelevant-file &&\n+\t\tgit commit -m A &&\n+\t\tgit tag A &&\n+\n+\t\tgit checkout -b B A &&\n+\t\tgit -C path reset --hard B &&\n+\t\tgit add path &&\n+\t\tgit commit -m B &&\n+\n+\t\tgit checkout -b C A &&\n+\t\trm -rf path/ &&\n+\t\ttest_ln_s_add irrelevant-file path &&\n+\t\tgit commit -m C &&\n+\n+\t\tgit checkout -q B^0 &&\n+\t\tgit merge -s ours -m D C^0 &&\n+\t\tgit tag D &&\n+\n+\t\tgit checkout -q C^0 &&\n+\t\tgit merge -s ours -m E B^0 &&\n+\t\tgit tag E\n+\t)\n+'\n+\n+test_expect_failure 'check conflicting entry types (submodule vs symlink)' '\n+\t(\n+\t\tcd submodule-symlink-add-add &&\n+\n+\t\tgit checkout D^0 &&\n+\n+\t\ttest_must_fail git merge -s recursive E^0 &&\n+\n+\t\tgit ls-files -s >out &&\n+\t\ttest_line_count = 3 out &&\n+\t\tgit ls-files -u >out &&\n+\t\ttest_line_count = 2 out &&\n+\t\tgit ls-files -o >out &&\n+\t\ttest_line_count = 1 out\n+\t)\n+'\n+\n test_done\n-- \n2.18.0.130.gd703bbb5d\n\n"},{"id":"351968","messageId":"xmqqr2kce1mw.fsf@gitster-ct.c.googlers.com","threadId":"48810","inReplyTo":"20180701041122.8753-1-newren@gmail.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-09T17:53:59Z","receivedAt":"2018-07-09T17:54:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> SPOILER ALERT: This series contains answers to the \"fun puzzle\" at\n>   https://public-inbox.org/git/CABPp-BFc1OLYKzS5rauOehvEugPc0oGMJp-NMEAmVMW7QR=4Eg@mail.gmail.com/\n>\n> When a merge succeeds, we expect the resulting contents to depend only\n> upon the trees and blobs of the branches involved and of their merge\n> base(s).  Unfortunately, there are currently about half a dozen cases\n> where the contents of a \"successful\" merge depend on the relative\n> commit timestamps of the merge bases.  Document these with testcases.\n>\n> (This series came out of looking at modifying how file collision\n> conflict types are handled, as discussed at [1].  I discovered these\n> issues while working on that topic.)\n\nI have a topic branch for this series but not merged to 'pu' as\ntest-lint gives these:\n\nt6036-recursive-corner-cases.sh:1222: error: \"export FOO=bar\" is not portable (please use FOO=bar && export FOO): \t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\nt6036-recursive-corner-cases.sh:1227: error: \"export FOO=bar\" is not portable (please use FOO=bar && export FOO): \t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\nMakefile:77: recipe for target 'test-lint-shell-syntax' failed\nmake: *** [test-lint-shell-syntax] Error 1\n\nArguably these are false positives because \"source_me.bash\" file is\na mere payload to go through the merge process to be munged and we\nnever intend to actually execute its contents with bash, but then\nthe test payload probably does not even have to be a string that\ntriggers such a false positive to begin with ;-)\n"},{"id":"352007","messageId":"20180709202229.10222-1-newren@gmail.com","threadId":"48810","inReplyTo":"xmqqr2kce1mw.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-09T20:22:29Z","receivedAt":"2018-07-09T20:22:37Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jul 9, 2018 at 10:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Elijah Newren <newren@gmail.com> writes:\n>\n>> When a merge succeeds, we expect the resulting contents to depend only\n>> upon the trees and blobs of the branches involved and of their merge\n>> base(s).  Unfortunately, there are currently about half a dozen cases\n>> where the contents of a \"successful\" merge depend on the relative\n>> commit timestamps of the merge bases.  Document these with testcases.\n>>\n>> (This series came out of looking at modifying how file collision\n>> conflict types are handled, as discussed at [1].  I discovered these\n>> issues while working on that topic.)\n>\n> I have a topic branch for this series but not merged to 'pu' as\n> test-lint gives these:\n>\n> t6036-recursive-corner-cases.sh:1222: error: \"export FOO=bar\" is not portable (please use FOO=bar && export FOO):               echo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n> t6036-recursive-corner-cases.sh:1227: error: \"export FOO=bar\" is not portable (please use FOO=bar && export FOO):               echo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n> Makefile:77: recipe for target 'test-lint-shell-syntax' failed\n> make: *** [test-lint-shell-syntax] Error 1\n>\n> Arguably these are false positives because \"source_me.bash\" file is\n> a mere payload to go through the merge process to be munged and we\n> never intend to actually execute its contents with bash, but then\n> the test payload probably does not even have to be a string that\n> triggers such a false positive to begin with ;-)\n\nOh, I didn't know about test-lint.  Is there a place that documents the various checks you run, so I can avoid slowing you down?  Ones I know about:\n\nAlready documented:\n  * `make DEVELOPER=1` (from CodingGuidelines)\n  * running tests (from SubmittingPatches)\n\nStuff I've seen you mention in emails over time:\n  * linux/scripts/checkpatch.pl\n  * git grep -e '\\<inline\\>' --and --not -e 'static inline' -- \\*.h\n  * make -C t/ test-lint\n\nAre there others?\n\n\nAlso, here's a fixup to the topic; as you pointed out, the exact contents\nof the script being written were actually irrelevant; it was just an\ninput to a merge.\n\n-- 8< --\nSubject: [PATCH] fixup! t6036: add a failed conflict detection case: regular\n files, different modes\n\n---\n t/t6036-recursive-corner-cases.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh\nindex f8f7b30460..5a8fe061ab 100755\n--- a/t/t6036-recursive-corner-cases.sh\n+++ b/t/t6036-recursive-corner-cases.sh\n@@ -1219,12 +1219,12 @@ test_expect_success 'setup conflicting modes for regular file' '\n \t\tgit tag A &&\n \n \t\tgit checkout -b B A &&\n-\t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n+\t\techo \"command_to_run\" >source_me.bash &&\n \t\tgit add source_me.bash &&\n \t\tgit commit -m B &&\n \n \t\tgit checkout -b C A &&\n-\t\techo \"export PATH=~/bin:$PATH\" >source_me.bash &&\n+\t\techo \"command_to_run\" >source_me.bash &&\n \t\tgit add source_me.bash &&\n \t\ttest_chmod +x source_me.bash &&\n \t\tgit commit -m C &&\n-- \n2.18.0.135.gd4ea5491ab\n\n"},{"id":"352063","messageId":"20180710044456.GA1870@sigill.intra.peff.net","threadId":"48810","inReplyTo":"20180709202229.10222-1-newren@gmail.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-10T04:44:56Z","receivedAt":"2018-07-10T04:45:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 09, 2018 at 01:22:29PM -0700, Elijah Newren wrote:\n\n> Oh, I didn't know about test-lint.  Is there a place that documents\n> the various checks you run, so I can avoid slowing you down?  Ones I\n> know about:\n> \n> Already documented:\n>   * `make DEVELOPER=1` (from CodingGuidelines)\n>   * running tests (from SubmittingPatches)\n> \n> Stuff I've seen you mention in emails over time:\n>   * linux/scripts/checkpatch.pl\n>   * git grep -e '\\<inline\\>' --and --not -e 'static inline' -- \\*.h\n>   * make -C t/ test-lint\n\ntest-lint is supposed to be run automatically as part of \"make test\" (or\n\"make prove\"), unless you've specifically disabled it by setting\nTEST_LINT. And it does complain for me with your patches. If it doesn't\nfor you, then we have a bug to fix. :)\n\nI won't be surprised, though, if you just ran \"./t6036\" manually before\nsending, since your patches literally didn't touch any other files.\n\nIn theory we could push some of the linting down into the test scripts\nthemselves (some of it, like the &&-linter, is there already by\nnecessity). But it might also end up annoying, since usually dropping\ndown to manual single-test runs means you're trying to debug something,\nand extra linting processes could get in the way.\n\n> Are there others?\n\nI like:\n\n  make SANITIZE=address,undefined test\n\nthough it's pretty heavy-weight (but not nearly as much as valgrind).\nYou probably also need BLK_SHA1=Yes, since the default DC_SHA1 has some\nunaligned loads that make UBSan complain. We should maybe teach the\nMakefile to do that by default.\n\nI've also been playing with clang's scan-build. It _did_ find a real bug\nrecently, but it has a bunch of false positives.\n\nStefan runs Coverity against pu periodically. IIRC It's a pain to run\nyourself, but the shared results can be mailed to you, or you can poke\naround at https://scan.coverity.com/projects/git. That _also_ has a ton\nof false positives, but it's good about cataloguing them so the periodic\nemail usually just mentions the new ones.\n\n-Peff\n"},{"id":"352116","messageId":"CABPp-BG5Rn=3MBS+daSJ+2rLsZWcswP3=8zX-F=5ncdzc9y=SQ@mail.gmail.com","threadId":"48810","inReplyTo":"20180710044456.GA1870@sigill.intra.peff.net","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-10T15:42:04Z","receivedAt":"2018-07-10T15:42:08Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jul 9, 2018 at 9:44 PM, Jeff King <peff@peff.net> wrote:\n> On Mon, Jul 09, 2018 at 01:22:29PM -0700, Elijah Newren wrote:\n>\n>> Oh, I didn't know about test-lint.  Is there a place that documents\n>> the various checks you run, so I can avoid slowing you down?  Ones I\n>> know about:\n>>\n>> Already documented:\n>>   * `make DEVELOPER=1` (from CodingGuidelines)\n>>   * running tests (from SubmittingPatches)\n>>\n>> Stuff I've seen you mention in emails over time:\n>>   * linux/scripts/checkpatch.pl\n>>   * git grep -e '\\<inline\\>' --and --not -e 'static inline' -- \\*.h\n>>   * make -C t/ test-lint\n>\n> test-lint is supposed to be run automatically as part of \"make test\" (or\n> \"make prove\"), unless you've specifically disabled it by setting\n> TEST_LINT. And it does complain for me with your patches. If it doesn't\n> for you, then we have a bug to fix. :)\n\nOh, this may be my bad.  Years ago someone pointed out that the\ntestsuite could be run under 'prove', which provided nicer output and\nmade sure to run the longest tests (e.g. the horrifically slow\nt9001-send-email.sh) first.  So my test alias is:\n\n   time prove -j7 --timer --state failed,slow,save t[0-9]*.sh ::\n\"--root=/dev/shm\"\n\n(with possibly different -j settings on different machines) and I just\nstopped running make test.  Didn't learn about the 'make prove'\ntarget, even though it's apparently now been there for nearly 8 years.\n\n> I won't be surprised, though, if you just ran \"./t6036\" manually before\n> sending, since your patches literally didn't touch any other files.\n\nThat may also be true, though I would have missed it even if I had\ncode changes due to not being aware of 'make prove'.\n\n> In theory we could push some of the linting down into the test scripts\n> themselves (some of it, like the &&-linter, is there already by\n> necessity). But it might also end up annoying, since usually dropping\n> down to manual single-test runs means you're trying to debug something,\n> and extra linting processes could get in the way.\n>\n>> Are there others?\n>\n> I like:\n>\n>   make SANITIZE=address,undefined test\n>\n> though it's pretty heavy-weight (but not nearly as much as valgrind).\n> You probably also need BLK_SHA1=Yes, since the default DC_SHA1 has some\n> unaligned loads that make UBSan complain. We should maybe teach the\n> Makefile to do that by default.\n>\n> I've also been playing with clang's scan-build. It _did_ find a real bug\n> recently, but it has a bunch of false positives.\n>\n> Stefan runs Coverity against pu periodically. IIRC It's a pain to run\n> yourself, but the shared results can be mailed to you, or you can poke\n> around at https://scan.coverity.com/projects/git. That _also_ has a ton\n> of false positives, but it's good about cataloguing them so the periodic\n> email usually just mentions the new ones.\n\nCool, thanks for the pointers.\n"},{"id":"352147","messageId":"20180710171957.GJ23624@sigill.intra.peff.net","threadId":"48810","inReplyTo":"CABPp-BG5Rn=3MBS+daSJ+2rLsZWcswP3=8zX-F=5ncdzc9y=SQ@mail.gmail.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-10T17:19:57Z","receivedAt":"2018-07-10T18:20:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 10, 2018 at 08:42:04AM -0700, Elijah Newren wrote:\n\n> > test-lint is supposed to be run automatically as part of \"make test\" (or\n> > \"make prove\"), unless you've specifically disabled it by setting\n> > TEST_LINT. And it does complain for me with your patches. If it doesn't\n> > for you, then we have a bug to fix. :)\n> \n> Oh, this may be my bad.  Years ago someone pointed out that the\n> testsuite could be run under 'prove', which provided nicer output and\n> made sure to run the longest tests (e.g. the horrifically slow\n> t9001-send-email.sh) first.  So my test alias is:\n> \n>    time prove -j7 --timer --state failed,slow,save t[0-9]*.sh ::\n> \"--root=/dev/shm\"\n\nHeh, OK, that makes sense.\n\n> (with possibly different -j settings on different machines) and I just\n> stopped running make test.  Didn't learn about the 'make prove'\n> target, even though it's apparently now been there for nearly 8 years.\n\nI have:\n\n  GIT_TEST_OPTS = --root=/var/ram/git-tests\n  GIT_PROVE_OPTS = -j16 --state=slow,save\n  DEFAULT_TEST_TARGET = prove\n\nin my config.mak. That lets me just do:\n\n  make test\n\nfrom the top-level to get a build-and-test. It also allows just \"make\"\nfrom the \"t\" directory to do the right thing.  Slightly annoyingly,\n\"make test\" in the \"t\" directory does the wrong thing, which bites me\nabout once a month. ;)\n\n-Peff\n"},{"id":"352197","messageId":"CABPp-BGH+6XkJwqhUOydT0CQBRTr=Hf79SU5PGZ2NrvV5uNjCw@mail.gmail.com","threadId":"48810","inReplyTo":"20180709202229.10222-1-newren@gmail.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-11T04:02:32Z","receivedAt":"2018-07-11T04:02:35Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jul 9, 2018 at 1:22 PM, Elijah Newren <newren@gmail.com> wrote:\n> On Mon, Jul 9, 2018 at 10:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Elijah Newren <newren@gmail.com> writes:\n>>\n>>> When a merge succeeds, we expect the resulting contents to depend only\n>>> upon the trees and blobs of the branches involved and of their merge\n>>> base(s).  Unfortunately, there are currently about half a dozen cases\n>>> where the contents of a \"successful\" merge depend on the relative\n>>> commit timestamps of the merge bases.  Document these with testcases.\n>>>\n>>> (This series came out of looking at modifying how file collision\n>>> conflict types are handled, as discussed at [1].  I discovered these\n>>> issues while working on that topic.)\n>>\n>> I have a topic branch for this series but not merged to 'pu' as\n>> test-lint gives these:\n>>\n...\n>\n> ... here's a fixup to the topic; as you pointed out, the exact contents\n> of the script being written were actually irrelevant; it was just an\n> input to a merge.\n>\n> -- 8< --\n> Subject: [PATCH] fixup! t6036: add a failed conflict detection case: regular\n>  files, different modes\n>\n\nDoes a 'fixup!' commit require a Signed-off-by?  Just realized that\nthis one didn't have it, though I don't know if it's necessary.  If it\nis:\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n"},{"id":"352259","messageId":"xmqqmuux4w83.fsf@gitster-ct.c.googlers.com","threadId":"48810","inReplyTo":"CABPp-BGH+6XkJwqhUOydT0CQBRTr=Hf79SU5PGZ2NrvV5uNjCw@mail.gmail.com","subject":"Re: [PATCH 0/6] Add merge recursive testcases with undetected conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-11T15:40:12Z","receivedAt":"2018-07-11T15:40:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> On Mon, Jul 9, 2018 at 1:22 PM, Elijah Newren <newren@gmail.com> wrote:\n>> On Mon, Jul 9, 2018 at 10:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Elijah Newren <newren@gmail.com> writes:\n>>>\n>>>> When a merge succeeds, we expect the resulting contents to depend only\n>>>> upon the trees and blobs of the branches involved and of their merge\n>>>> base(s).  Unfortunately, there are currently about half a dozen cases\n>>>> where the contents of a \"successful\" merge depend on the relative\n>>>> commit timestamps of the merge bases.  Document these with testcases.\n>>>>\n>>>> (This series came out of looking at modifying how file collision\n>>>> conflict types are handled, as discussed at [1].  I discovered these\n>>>> issues while working on that topic.)\n>>>\n>>> I have a topic branch for this series but not merged to 'pu' as\n>>> test-lint gives these:\n>>>\n> ...\n>>\n>> ... here's a fixup to the topic; as you pointed out, the exact contents\n>> of the script being written were actually irrelevant; it was just an\n>> input to a merge.\n>>\n>> -- 8< --\n>> Subject: [PATCH] fixup! t6036: add a failed conflict detection case: regular\n>>  files, different modes\n>>\n>\n> Does a 'fixup!' commit require a Signed-off-by?  Just realized that\n> this one didn't have it, though I don't know if it's necessary.  If it\n> is:\n>\n> Signed-off-by: Elijah Newren <newren@gmail.com>\n\nThanks.  I queued it separately before running out of time Monday,\nbut will actually squash it in to the main patch.\n\n"}]}