{"thread":{"id":"46075","subject":"[PATCH 0/3] Add regression tests for recent rebase -i fixes","startedAt":"2017-05-31T10:42:39Z","lastAt":"2017-06-26T09:23:19Z","messageCount":59,"participants":["Phillip Wood","Junio C Hamano","Johannes Schindelin","Stefan Beller","Jonathan Nieder","Ævar Arnfjörð Bjarmason","Samuel Lijin","Brandon Williams","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"321122","messageId":"20170531104213.16944-1-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":null,"subject":"[PATCH 0/3] Add regression tests for recent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-05-31T10:42:10Z","receivedAt":"2017-05-31T10:42:39Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nThese patches add some tests for the fixes I sent the week before\nlast. The output tests check the messages for stashes that apply and\nfail for all three variants of rebase. They are quite strict but I\ncouldn't think of a better way to check that the output is correct and\ndoesn't contain anything it isn't meant to (such as the output of git\nstatus).\n\n\nPhillip Wood (3):\n rebase -i: Add test for reflog message\n rebase: Add tests for console output\n rebase: Add tests for console output with conflicting stash\n\n t/t3404-rebase-interactive.sh | 7 +++++++\n t/t3420-rebase-autostash.sh | 20 ++++++++++++++++++--\n t/t3420/expected-fail-am | 8 ++++++++\n t/t3420/expected-fail-interactive | 6 ++++++\n t/t3420/expected-fail-merge | 32 ++++++++++++++++++++++++++++++++\n t/t3420/expected-success-am | 6 ++++++\n t/t3420/expected-success-interactive | 4 ++++\n t/t3420/expected-success-merge | 30 ++++++++++++++++++++++++++++++\n t/t3420/remove-ids.sed | 6 ++++++\n 9 files changed, 117 insertions(+), 2 deletions(-)\n create mode 100644 t/t3420/expected-fail-am\n create mode 100644 t/t3420/expected-fail-interactive\n create mode 100644 t/t3420/expected-fail-merge\n create mode 100644 t/t3420/expected-success-am\n create mode 100644 t/t3420/expected-success-interactive\n create mode 100644 t/t3420/expected-success-merge\n create mode 100644 t/t3420/remove-ids.sed\n\n-- \n2.13.0\n\n"},{"id":"321123","messageId":"20170531104213.16944-4-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-1-phillip.wood@talktalk.net","subject":"[PATCH 3/3] rebase: Add tests for console output with conflicting stash","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-05-31T10:42:13Z","receivedAt":"2017-05-31T10:42:41Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck that the console output is what we expect when restoring\nautostashed changes fails.\n\nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 10 +++++++++-\n t/t3420/expected-fail-am | 8 ++++++++\n t/t3420/expected-fail-interactive | 6 ++++++\n t/t3420/expected-fail-merge | 32 ++++++++++++++++++++++++++++++++\n 4 files changed, 55 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 886be63c6d13e1ac4197a1b185659fb3d7d7eb26..4ff0d7aebd66b0ce091ceb11986b3928503c8c5f 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -148,7 +148,7 @@ testrebase() {\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >file4 &&\n \t\tgit add file4 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >tmp 2>&1 &&\n \t\ttest_path_is_missing $dotest &&\n \t\tgit reset --hard &&\n \t\tgrep unrelated file4 &&\n@@ -157,6 +157,14 @@ testrebase() {\n \t\tgit stash pop &&\n \t\tgrep dirty file4\n \t'\n+\n+\ttest_expect_success \"rebase$type: check output with conflicting stash\" '\n+\t\tsuffix=${type#\\ -} && suffix=${suffix:--am} &&\n+\t\tsed -f $TEST_DIRECTORY/t3420/remove-ids.sed tmp \\\n+\t\t\t>actual-fail$suffix &&\n+\t\ttest_cmp $TEST_DIRECTORY/t3420/expected-fail$suffix \\\n+\t\t\tactual-fail$suffix\n+\t'\n }\n \n test_expect_success \"rebase: fast-forward rebase\" '\ndiff --git a/t/t3420/expected-fail-am b/t/t3420/expected-fail-am\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..1d643fa2ef7e67f1ad1a49a02e81d2d6c66e6920\n--- /dev/null\n+++ b/t/t3420/expected-fail-am\n@@ -0,0 +1,8 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+First, rewinding head to replay your work on top of it...\n+Applying: second commit\n+Applying: third commit\n+Applying autostash resulted in conflicts.\n+Your changes are safe in the stash.\n+You can run \"git stash pop\" or \"git stash drop\" at any time.\ndiff --git a/t/t3420/expected-fail-interactive b/t/t3420/expected-fail-interactive\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..9d1dd5264237e8f58e1960c6c0fb5b736df6f86d\n--- /dev/null\n+++ b/t/t3420/expected-fail-interactive\n@@ -0,0 +1,6 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+Rebasing (1/2)\\rRebasing (2/2)\\rSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n+Applying autostash resulted in conflicts.\n+Your changes are safe in the stash.\n+You can run \"git stash pop\" or \"git stash drop\" at any time.\ndiff --git a/t/t3420/expected-fail-merge b/t/t3420/expected-fail-merge\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..5dcb2ff3acdb93f55131d67ae227d231e097a2a2\n--- /dev/null\n+++ b/t/t3420/expected-fail-merge\n@@ -0,0 +1,32 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+First, rewinding head to replay your work on top of it...\n+Merging unrelated-onto-branch with HEAD~1\n+Merging:\n+XXX unrelated commit\n+XXX second commit\n+found 1 common ancestor:\n+XXX initial commit\n+[detached HEAD XXX] second commit\n+ Author: A U Thor \n+ Date: Thu Apr 7 15:14:13 2005 -0700\n+ 2 files changed, 2 insertions(+)\n+ create mode 100644 file1\n+ create mode 100644 file2\n+Committed: 0001 second commit\n+Merging unrelated-onto-branch with HEAD~0\n+Merging:\n+XXX second commit\n+XXX third commit\n+found 1 common ancestor:\n+XXX second commit\n+[detached HEAD XXX] third commit\n+ Author: A U Thor \n+ Date: Thu Apr 7 15:15:13 2005 -0700\n+ 1 file changed, 1 insertion(+)\n+ create mode 100644 file3\n+Committed: 0002 third commit\n+All done.\n+Applying autostash resulted in conflicts.\n+Your changes are safe in the stash.\n+You can run \"git stash pop\" or \"git stash drop\" at any time.\n-- \n2.13.0\n\n"},{"id":"321124","messageId":"20170531104213.16944-2-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-1-phillip.wood@talktalk.net","subject":"[PATCH 1/3] rebase -i: Add test for reflog message","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-05-31T10:42:11Z","receivedAt":"2017-05-31T10:42:42Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck that the reflog message written to the branch reflog when the\nrebase is completed is correct. This checks for regressions for the\nfix in commit\n4ab867b8fc rebase -i: fix reflog message\n\nSigned-off-by: Phillip Wood \n---\n t/t3404-rebase-interactive.sh | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 5bd0275930b715c25507fc9744c8946e7f73900b..37821d245433f757fa13f0a3e27da0312bebb7db 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -169,6 +169,13 @@ test_expect_success 'reflog for the branch shows state before rebase' '\n \ttest $(git rev-parse branch1@{1}) = $(git rev-parse original-branch1)\n '\n \n+test_expect_success 'reflog for the branch shows correct finish message' '\n+\tprintf \"rebase -i (finish): refs/heads/branch1 onto %s\\n\" \\\n+\t\t\"$(git rev-parse branch2)\" >expected &&\n+\tgit log -g --pretty=%gs -1 refs/heads/branch1 >actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_expect_success 'exchange two commits' '\n \tset_fake_editor &&\n \tFAKE_LINES=\"2 1\" git rebase -i HEAD~2 &&\n-- \n2.13.0\n\n"},{"id":"321125","messageId":"20170531104213.16944-3-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-1-phillip.wood@talktalk.net","subject":"[PATCH 2/3] rebase: Add tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-05-31T10:42:12Z","receivedAt":"2017-05-31T10:42:44Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck the console output when using --autostash and the stash applies\ncleanly is what we expect. To avoid this test depending on commit and\nstash hashes it uses sed to replace them with XXX. The sed script also\nreplaces carriage returns in the output with '\\r' to avoid embedded\n'^M's in the expected output files. Unfortunately this means we still\nend up with an embedded '^M' in the sed script which may not be\npreserved when sending this. The last line of the sed script should be\n+s/^M/\\\\r/g\n\nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 10 +++++++++-\n t/t3420/expected-success-am | 6 ++++++\n t/t3420/expected-success-interactive | 4 ++++\n t/t3420/expected-success-merge | 30 ++++++++++++++++++++++++++++++\n t/t3420/remove-ids.sed | 6 ++++++\n 5 files changed, 55 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex ab8a63e8d6dc643b28eb0c74ba3f032b7532226f..886be63c6d13e1ac4197a1b185659fb3d7d7eb26 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -53,12 +53,20 @@ testrebase() {\n \t\tgit checkout -b rebased-feature-branch feature-branch &&\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >>file3 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >tmp 2>&1 &&\n \t\tgrep unrelated file4 &&\n \t\tgrep dirty file3 &&\n \t\tgit checkout feature-branch\n \t'\n \n+\ttest_expect_success \"rebase$type --autostash: check output\" '\n+\t\tsuffix=${type#\\ -} && suffix=${suffix:--am} &&\n+\t\tsed -f $TEST_DIRECTORY/t3420/remove-ids.sed tmp \\\n+\t\t\t>actual-success$suffix &&\n+\t\ttest_cmp $TEST_DIRECTORY/t3420/expected-success$suffix \\\n+\t\t\tactual-success$suffix\n+\t'\n+\n \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\ndiff --git a/t/t3420/expected-success-am b/t/t3420/expected-success-am\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..c18ded04f703ed2aa83d5e62589a908d0a44cf7e\n--- /dev/null\n+++ b/t/t3420/expected-success-am\n@@ -0,0 +1,6 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+First, rewinding head to replay your work on top of it...\n+Applying: second commit\n+Applying: third commit\n+Applied autostash.\ndiff --git a/t/t3420/expected-success-interactive b/t/t3420/expected-success-interactive\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..b31f71c95ddc9c18ce9956c1aadf53cedd966801\n--- /dev/null\n+++ b/t/t3420/expected-success-interactive\n@@ -0,0 +1,4 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+Rebasing (1/2)\\rRebasing (2/2)\\rSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n+Applied autostash.\ndiff --git a/t/t3420/expected-success-merge b/t/t3420/expected-success-merge\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..66386f7cb5242a255d9cc64aad741e651ec7ec1e\n--- /dev/null\n+++ b/t/t3420/expected-success-merge\n@@ -0,0 +1,30 @@\n+Created autostash: XXX\n+HEAD is now at XXX third commit\n+First, rewinding head to replay your work on top of it...\n+Merging unrelated-onto-branch with HEAD~1\n+Merging:\n+XXX unrelated commit\n+XXX second commit\n+found 1 common ancestor:\n+XXX initial commit\n+[detached HEAD XXX] second commit\n+ Author: A U Thor \n+ Date: Thu Apr 7 15:14:13 2005 -0700\n+ 2 files changed, 2 insertions(+)\n+ create mode 100644 file1\n+ create mode 100644 file2\n+Committed: 0001 second commit\n+Merging unrelated-onto-branch with HEAD~0\n+Merging:\n+XXX second commit\n+XXX third commit\n+found 1 common ancestor:\n+XXX second commit\n+[detached HEAD XXX] third commit\n+ Author: A U Thor \n+ Date: Thu Apr 7 15:15:13 2005 -0700\n+ 1 file changed, 1 insertion(+)\n+ create mode 100644 file3\n+Committed: 0002 third commit\n+All done.\n+Applied autostash.\ndiff --git a/t/t3420/remove-ids.sed b/t/t3420/remove-ids.sed\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..9e9048b02bd04d287461543d85db0bb715b89f8c\n--- /dev/null\n+++ b/t/t3420/remove-ids.sed\n@@ -0,0 +1,6 @@\n+s/^\\(Created autostash: \\)[0-9a-f]\\{6,\\}$/\\1XXX/\n+s/^\\(HEAD is now at \\)[0-9a-f]\\{6,\\}\\( .* commit\\)$/\\1XXX\\2/\n+s/^[0-9a-f]\\{6,\\}\\( .* commit\\)$/XXX\\1/\n+s/\\(detached HEAD \\)[0-9a-f]\\{6,\\}/\\1XXX/\n+s/\\(could not apply \\)[0-9a-f]\\{6,\\}/\\1XXX/g\n+s/\r/\\\\r/g\n-- \n2.13.0\n\n"},{"id":"321154","messageId":"39cd140a-4ba1-f3ee-d945-bf43199d4a82@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-3-phillip.wood@talktalk.net","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-05-31T19:02:53Z","receivedAt":"2017-05-31T19:03:01Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 31/05/17 11:42, Phillip Wood wrote:\n> From: Phillip Wood \n> \n> Check the console output when using --autostash and the stash applies\n> cleanly is what we expect. To avoid this test depending on commit and\n> stash hashes it uses sed to replace them with XXX. The sed script also\n> replaces carriage returns in the output with '\\r' to avoid embedded\n> '^M's in the expected output files. Unfortunately this means we still\n> end up with an embedded '^M' in the sed script which may not be\n> preserved when sending this. The last line of the sed script should be\n> +s/^M/\\\\r/g\n\nThinking about this it might be better to create the sed script with \nprintf when running the test\n\n> Signed-off-by: Phillip Wood \n> ---\n> t/t3420-rebase-autostash.sh | 10 +++++++++-\n> t/t3420/expected-success-am | 6 ++++++\n> t/t3420/expected-success-interactive | 4 ++++\n> t/t3420/expected-success-merge | 30 ++++++++++++++++++++++++++++++\n> t/t3420/remove-ids.sed | 6 ++++++\n> 5 files changed, 55 insertions(+), 1 deletion(-)\n> \n> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n> index ab8a63e8d6dc643b28eb0c74ba3f032b7532226f..886be63c6d13e1ac4197a1b185659fb3d7d7eb26 100755\n> --- a/t/t3420-rebase-autostash.sh\n> +++ b/t/t3420-rebase-autostash.sh\n> @@ -53,12 +53,20 @@ testrebase() {\n> \t\tgit checkout -b rebased-feature-branch feature-branch &&\n> \t\ttest_when_finished git branch -D rebased-feature-branch &&\n> \t\techo dirty >>file3 &&\n> -\t\tgit rebase$type unrelated-onto-branch &&\n> +\t\tgit rebase$type unrelated-onto-branch >tmp 2>&1 &&\n> \t\tgrep unrelated file4 &&\n> \t\tgrep dirty file3 &&\n> \t\tgit checkout feature-branch\n> \t'\n> \n> +\ttest_expect_success \"rebase$type --autostash: check output\" '\n> +\t\tsuffix=${type#\\ -} && suffix=${suffix:--am} &&\n> +\t\tsed -f $TEST_DIRECTORY/t3420/remove-ids.sed tmp \\\n> +\t\t\t>actual-success$suffix &&\n> +\t\ttest_cmp $TEST_DIRECTORY/t3420/expected-success$suffix \\\n> +\t\t\tactual-success$suffix\n> +\t'\n> +\n> \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n> \t\ttest_config rebase.autostash true &&\n> \t\tgit reset --hard &&\n> diff --git a/t/t3420/expected-success-am b/t/t3420/expected-success-am\n> new file mode 100644\n> index 0000000000000000000000000000000000000000..c18ded04f703ed2aa83d5e62589a908d0a44cf7e\n> --- /dev/null\n> +++ b/t/t3420/expected-success-am\n> @@ -0,0 +1,6 @@\n> +Created autostash: XXX\n> +HEAD is now at XXX third commit\n> +First, rewinding head to replay your work on top of it...\n> +Applying: second commit\n> +Applying: third commit\n> +Applied autostash.\n> diff --git a/t/t3420/expected-success-interactive b/t/t3420/expected-success-interactive\n> new file mode 100644\n> index 0000000000000000000000000000000000000000..b31f71c95ddc9c18ce9956c1aadf53cedd966801\n> --- /dev/null\n> +++ b/t/t3420/expected-success-interactive\n> @@ -0,0 +1,4 @@\n> +Created autostash: XXX\n> +HEAD is now at XXX third commit\n> +Rebasing (1/2)\\rRebasing (2/2)\\rSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n> +Applied autostash.\n> diff --git a/t/t3420/expected-success-merge b/t/t3420/expected-success-merge\n> new file mode 100644\n> index 0000000000000000000000000000000000000000..66386f7cb5242a255d9cc64aad741e651ec7ec1e\n> --- /dev/null\n> +++ b/t/t3420/expected-success-merge\n> @@ -0,0 +1,30 @@\n> +Created autostash: XXX\n> +HEAD is now at XXX third commit\n> +First, rewinding head to replay your work on top of it...\n> +Merging unrelated-onto-branch with HEAD~1\n> +Merging:\n> +XXX unrelated commit\n> +XXX second commit\n> +found 1 common ancestor:\n> +XXX initial commit\n> +[detached HEAD XXX] second commit\n> + Author: A U Thor \n> + Date: Thu Apr 7 15:14:13 2005 -0700\n> + 2 files changed, 2 insertions(+)\n> + create mode 100644 file1\n> + create mode 100644 file2\n> +Committed: 0001 second commit\n> +Merging unrelated-onto-branch with HEAD~0\n> +Merging:\n> +XXX second commit\n> +XXX third commit\n> +found 1 common ancestor:\n> +XXX second commit\n> +[detached HEAD XXX] third commit\n> + Author: A U Thor \n> + Date: Thu Apr 7 15:15:13 2005 -0700\n> + 1 file changed, 1 insertion(+)\n> + create mode 100644 file3\n> +Committed: 0002 third commit\n> +All done.\n> +Applied autostash.\n> diff --git a/t/t3420/remove-ids.sed b/t/t3420/remove-ids.sed\n> new file mode 100644\n> index 0000000000000000000000000000000000000000..9e9048b02bd04d287461543d85db0bb715b89f8c\n> --- /dev/null\n> +++ b/t/t3420/remove-ids.sed\n> @@ -0,0 +1,6 @@\n> +s/^\\(Created autostash: \\)[0-9a-f]\\{6,\\}$/\\1XXX/\n> +s/^\\(HEAD is now at \\)[0-9a-f]\\{6,\\}\\( .* commit\\)$/\\1XXX\\2/\n> +s/^[0-9a-f]\\{6,\\}\\( .* commit\\)$/XXX\\1/\n> +s/\\(detached HEAD \\)[0-9a-f]\\{6,\\}/\\1XXX/\n> +s/\\(could not apply \\)[0-9a-f]\\{6,\\}/\\1XXX/g\n> +s//\\\\r/g\n> \n\n"},{"id":"321237","messageId":"xmqq7f0w8o3l.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"39cd140a-4ba1-f3ee-d945-bf43199d4a82@talktalk.net","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-01T01:59:26Z","receivedAt":"2017-06-01T01:59:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> On 31/05/17 11:42, Phillip Wood wrote:\n>> From: Phillip Wood \n>>\n>> Check the console output when using --autostash and the stash applies\n>> cleanly is what we expect. To avoid this test depending on commit and\n>> stash hashes it uses sed to replace them with XXX. The sed script also\n>> replaces carriage returns in the output with '\\r' to avoid embedded\n>> '^M's in the expected output files. Unfortunately this means we still\n>> end up with an embedded '^M' in the sed script which may not be\n>> preserved when sending this.\n\nOr such a sed script may simply be not portable.\n"},{"id":"321238","messageId":"xmqq37bk8o2h.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170531104213.16944-2-phillip.wood@talktalk.net","subject":"Re: [PATCH 1/3] rebase -i: Add test for reflog message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-01T02:00:06Z","receivedAt":"2017-06-01T02:00:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> From: Phillip Wood \n>\n> Check that the reflog message written to the branch reflog when the\n> rebase is completed is correct. This checks for regressions for the\n> fix in commit\n> 4ab867b8fc rebase -i: fix reflog message\n>\n> Signed-off-by: Phillip Wood \n> ---\n\nGood idea. Thanks.\n\n> t/t3404-rebase-interactive.sh | 7 +++++++\n> 1 file changed, 7 insertions(+)\n>\n> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\n> index 5bd0275930b715c25507fc9744c8946e7f73900b..37821d245433f757fa13f0a3e27da0312bebb7db 100755\n> --- a/t/t3404-rebase-interactive.sh\n> +++ b/t/t3404-rebase-interactive.sh\n> @@ -169,6 +169,13 @@ test_expect_success 'reflog for the branch shows state before rebase' '\n> \ttest $(git rev-parse branch1@{1}) = $(git rev-parse original-branch1)\n> '\n> \n> +test_expect_success 'reflog for the branch shows correct finish message' '\n> +\tprintf \"rebase -i (finish): refs/heads/branch1 onto %s\\n\" \\\n> +\t\t\"$(git rev-parse branch2)\" >expected &&\n> +\tgit log -g --pretty=%gs -1 refs/heads/branch1 >actual &&\n> +\ttest_cmp expected actual\n> +'\n> +\n> test_expect_success 'exchange two commits' '\n> \tset_fake_editor &&\n> \tFAKE_LINES=\"2 1\" git rebase -i HEAD~2 &&\n"},{"id":"321283","messageId":"alpine.DEB.2.21.1.1706011329350.3610@virtualbox","threadId":"46075","inReplyTo":"20170531104213.16944-3-phillip.wood@talktalk.net","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-01T12:56:13Z","receivedAt":"2017-06-01T12:56:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 31 May 2017, Phillip Wood wrote:\n\n> From: Phillip Wood \n> \n> Check the console output when using --autostash and the stash applies\n> cleanly is what we expect. To avoid this test depending on commit and\n> stash hashes it uses sed to replace them with XXX. The sed script also\n> replaces carriage returns in the output with '\\r' to avoid embedded\n> '^M's in the expected output files. Unfortunately this means we still\n> end up with an embedded '^M' in the sed script which may not be\n> preserved when sending this. The last line of the sed script should be\n> +s/^M/\\\\r/g\n\nLike Junio pointed out, this sed script would not be portable. To\nelaborate: there are two major variants of sed out there, GNU sed and BSD\nsed. Typically GNU sed allows a little more powerful instructions, e.g. \\t\nand \\r.\n\nBut we should simply take a step back and ask why test_cmp is not enough\nto ignore the CRs in the output?\n\nAlso, about the commit IDs. As long as the tests are consistent (i.e. they\nuse test_commit rather than plain `git commit`, or at least call\n`test_tick` beforehand), the commit IDs should actually be identical\nbetween runs and not depend on the time of day or the date.\n\nThe only exception to that rule is when some previous test cases call\n`test_commit` but are guarded behind some prereq and may not be executed\nat all. In that case, the precise commit IDs depend on the particular set\nof active prereqs.\n\nBut as far as I can tell, t3420 does not have any test cases guarded by\nprereqs.\n\nTaking an additional step back, I wonder whether we have to hard-code the\ncommit IDs (or XXX) to begin with. Why not generate the `expect` files\nwith the information at hand? We can simply ask `git rev-parse --short`.\n\nFor the stash's commit ID, there is no record in the ref space, of course\n(because it was created with `git stash create`). But I think in this\ncase, it is legitimate to simply grep the output.\n\nThat way, the test would be precise and resilient.\n\nSo for example instead of adding the t/t3420/expected-success-am verbatim,\nyou could generate the output via\n\n\tcat >expect <<-EOF\n\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\\\$\" output)\n\tHEAD is now at $(git rev-parse --short HEAD~2) third commit\n\tFirst, rewinding head to replay your work on top of it...\n\tApplying: second commit\n\tApplying: third commit\n\tApplied autostash.\n\tEOF\n\nCiao,\nJohannes\n"},{"id":"321356","messageId":"xmqq7f0v46q3.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706011329350.3610@virtualbox","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-01T23:40:36Z","receivedAt":"2017-06-01T23:40:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Also, about the commit IDs. As long as the tests are consistent (i.e. they\n> use test_commit rather than plain `git commit`, or at least call\n> `test_tick` beforehand), the commit IDs should actually be identical\n> between runs and not depend on the time of day or the date.\n>\n> The only exception to that rule is when some previous test cases call\n> `test_commit` but are guarded behind some prereq and may not be executed\n> at all. In that case, the precise commit IDs depend on the particular set\n> of active prereqs.\n\nGood observation. The tests written such a way may make later\nintroduction of new hash function troublesome, though (we already\nhave tons of them, and it is already a hassle just imagining that we\nwill have to migrate them X-<). \n\nAnd what you gave below is an excellent suggestion to even solve\nthat future headaches.\n\n> But as far as I can tell, t3420 does not have any test cases guarded by\n> prereqs.\n>\n> Taking an additional step back, I wonder whether we have to hard-code the\n> commit IDs (or XXX) to begin with. Why not generate the `expect` files\n> with the information at hand? We can simply ask `git rev-parse --short`.\n>\n> For the stash's commit ID, there is no record in the ref space, of course\n> (because it was created with `git stash create`). But I think in this\n> case, it is legitimate to simply grep the output.\n>\n> That way, the test would be precise and resilient.\n>\n> So for example instead of adding the t/t3420/expected-success-am verbatim,\n> you could generate the output via\n>\n> \tcat >expect <<-EOF\n> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\\\$\" output)\n> \tHEAD is now at $(git rev-parse --short HEAD~2) third commit\n> \tFirst, rewinding head to replay your work on top of it...\n> \tApplying: second commit\n> \tApplying: third commit\n> \tApplied autostash.\n> \tEOF\n>\n> Ciao,\n> Johannes\n"},{"id":"321357","messageId":"CAGZ79kaM9ryT1gWx=L6S90HPCaDPNZ6H124HAJscpeJCQFDN8Q@mail.gmail.com","threadId":"46075","inReplyTo":"xmqq7f0v46q3.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-01T23:47:44Z","receivedAt":"2017-06-01T23:48:06Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jun 1, 2017 at 4:40 PM, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>\n>> Also, about the commit IDs. As long as the tests are consistent (i.e. they\n>> use test_commit rather than plain `git commit`, or at least call\n>> `test_tick` beforehand), the commit IDs should actually be identical\n>> between runs and not depend on the time of day or the date.\n>>\n>> The only exception to that rule is when some previous test cases call\n>> `test_commit` but are guarded behind some prereq and may not be executed\n>> at all. In that case, the precise commit IDs depend on the particular set\n>> of active prereqs.\n>\n> Good observation. The tests written such a way may make later\n> introduction of new hash function troublesome, though (we already\n> have tons of them, and it is already a hassle just imagining that we\n> will have to migrate them X-<).\n>\n> And what you gave below is an excellent suggestion to even solve\n> that future headaches.\n>\n\nWe had a discussion off list how much of the test suite is in bad shape,\nand \"$ git grep ^index\" points out a lot of places as well.\n"},{"id":"321403","messageId":"alpine.DEB.2.21.1.1706021442190.171564@virtualbox","threadId":"46075","inReplyTo":"CAGZ79kaM9ryT1gWx=L6S90HPCaDPNZ6H124HAJscpeJCQFDN8Q@mail.gmail.com","subject":"pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-02T12:47:44Z","receivedAt":"2017-06-02T12:48:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Jun 2017, Stefan Beller wrote:\n\n> On Thu, Jun 1, 2017 at 4:40 PM, Junio C Hamano wrote:\n> > Johannes Schindelin writes:\n> >\n> >> Also, about the commit IDs. As long as the tests are consistent (i.e. they\n> >> use test_commit rather than plain `git commit`, or at least call\n> >> `test_tick` beforehand), the commit IDs should actually be identical\n> >> between runs and not depend on the time of day or the date.\n> >>\n> >> The only exception to that rule is when some previous test cases call\n> >> `test_commit` but are guarded behind some prereq and may not be executed\n> >> at all. In that case, the precise commit IDs depend on the particular set\n> >> of active prereqs.\n> >\n> > Good observation. The tests written such a way may make later\n> > introduction of new hash function troublesome, though (we already\n> > have tons of them, and it is already a hassle just imagining that we\n> > will have to migrate them X-<).\n> >\n> > And what you gave below is an excellent suggestion to even solve\n> > that future headaches.\n> \n> We had a discussion off list how much of the test suite is in bad shape,\n> and \"$ git grep ^index\" points out a lot of places as well.\n\nMaybe we should call out a specific month (or even a longer period) during\nwhich we try to push toward that new hash function, and focus more on\nthose tasks (and on critical bug fixes, if any) than anything else.\n\nI also wonder how we can attract (back) cryptographic talent to help us\navoid repeating mistakes when picking a new hash algorithm.\n\nSo far, the only undisputable expert opinion I read was from the Keccak\nteam, and I did not have the impression that their opinion had any impact\non the discussion. Needless to say: I think it should. Cryptography is\nhard. We proved it ;-)\n\nCiao,\nDscho\n"},{"id":"321413","messageId":"20170602175455.GA30988@aiede.mtv.corp.google.com","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706021442190.171564@virtualbox","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-06-02T17:54:55Z","receivedAt":"2017-06-02T17:55:49Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Dscho,\n\nJohannes Schindelin wrote:\n> On Thu, 1 Jun 2017, Stefan Beller wrote:\n\n>> We had a discussion off list how much of the test suite is in bad shape,\n>> and \"$ git grep ^index\" points out a lot of places as well.\n>\n> Maybe we should call out a specific month (or even a longer period) during\n> which we try to push toward that new hash function, and focus more on\n> those tasks (and on critical bug fixes, if any) than anything else.\n\nThanks for offering. ;-)\n\nHere's a rough list of some useful tasks, in no particular order:\n\n1. bc/object-id: This patch series continues, eliminating assumptions\n about the size of object ids by encapsulating them in a struct.\n One straightforward way to find code that still needs to be\n converted is to grep for \"sha\" --- often the conversion patches\n change function and variable names to refer to oid_ where they used\n to use sha1_, making the stragglers easier to spot.\n\n2. Hard-coded object ids in tests: As Stefan hinted, many tests beyond\n t00* make assumptions about the exact values of object ids. That's\n bad for maintainability for other reasons beyond the hash function\n transition, too.\n\n It should be possible to suss them out by patching git's sha1\n routine to use the ones-complement of sha1 (~sha1) instead and\n seeing which tests fail.\n\n3. Repository format extension to use a different hash function: we\n want git to be able to work with two hash functions: sha1 and\n something else. For interoperability and simplity, it is useful\n for a single git binary to support both hash functions.\n\n That means a repository needs to be able to specify what hash\n function is used for the objects in that repository. This can be\n configured by setting '[core] repositoryformatversion=1' (to avoid\n confusing old versions of git) and\n '[extensions] experimentalNewHashFunction = true'.\n Documentation/technical/repository-version.txt has more details.\n\n We can start experimenting with this using e.g. the ~sha1 function\n described at (2), or the 160-bit hash of the patch author's choice\n (e.g. truncated blake2bp-256).\n\n4. When choosing a hash function, people may argue about performance.\n It would be useful for run some benchmarks for git (running\n the test suite, t/perf tests, etc) using a variety of hash\n functions as input to such a discussion.\n\n5. Longer hash: Even once all object id references in git use struct\n object_id (see (1)), we need to tackle other assumptions about\n object id size in git and its tests.\n\n It should be possible to suss them out by replacing git's sha1\n routine with a 40-byte hash: sha1 with each byte repeated (sha1+sha1)\n and seeing what fails.\n\n6. Repository format extension for longer hash: As in (3), we could\n add a repository format extension to experiment with using the\n sha1+sha1 function.\n\n7. Avoiding wasted memory from unused hash functions: struct object_id\n has definition 'unsigned char hash[GIT_MAX_RAWSZ]', where\n GIT_MAX_RAWSZ is the size of the largest supported hash function.\n When operating on a repository that only uses sha1, this wastes\n memory.\n\n Avoid that by making object identifiers variable-sized. That is,\n something like\n\n struct object_id {\n \tunion {\n\t unsigned char hash20[20];\n\t unsigned char hash32[32];\n\t} *hash;\n }\n\n or\n\n struct object_id {\n unsigned char *hash;\n }\n\n The hard part is that allocation and destruction have to be\n explicit instead of happening automatically when an object_id is an\n automatic variable.\n\n8. Implement\n http://public-inbox.org/git/20170307001709.GC26789@aiede.mtv.corp.google.com/\n :) I'd like to send a breakdown of that too, but that probably\n should happen in a separate message.\n\n9. We can use help from security experts in all of this. Fuzzing,\n analysis of how we use cryptography, security review of other parts\n of the design, and information to help choose a hash function are\n all appreciated.\n\n> I also wonder how we can attract (back) cryptographic talent to help us\n> avoid repeating mistakes when picking a new hash algorithm.\n>\n> So far, the only undisputable expert opinion I read was from the Keccak\n> team, and I did not have the impression that their opinion had any impact\n> on the discussion. Needless to say: I think it should. Cryptography is\n> hard. We proved it ;-)\n\nDo you have some ideas in mind here?\n\nHow did you get the impression that their opinion had no impact? We\nhave been getting feedback about the choice of hash function both on\nand off list from a variety of people, some indisputably security\nexperts. Sometimes the best one can do is to just listen.\n\nFor what it's worth my personal opinion is currently leaning toward\nblake2bp-256 as choice of hash function, not SHA2 or SHA3. But we\nstill have time to learn more and make a better decision.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"321414","messageId":"20170602180515.GB30988@aiede.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170602175455.GA30988@aiede.mtv.corp.google.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-06-02T18:05:15Z","receivedAt":"2017-06-02T18:05:24Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> Here's a rough list of some useful tasks, in no particular order:\n>\n> 1. bc/object-id: This patch series continues, eliminating assumptions\n> about the size of object ids by encapsulating them in a struct.\n> One straightforward way to find code that still needs to be\n> converted is to grep for \"sha\" --- often the conversion patches\n> change function and variable names to refer to oid_ where they used\n> to use sha1_, making the stragglers easier to spot.\n\nI forgot to say: please coordinate with Brian M. Carlson if working on\nthis one. That makes it possible to divide up the work in a way that\ndoesn't lead to people patching the same files and stepping on each\nother's toes.\n\nThis is one of the larger tasks and contributions to it are very\nuseful. Just do coordinate.\n\nFor comparison, the other suggestions in the list should be possible\nfor a rogue agent to experiment with alone, with advice from the list\nwhere they need it. :)\n\nJonathan\n"},{"id":"321440","messageId":"CACBZZX7JRA2niwt9wsGAxnzS+gWS8hTUgzWm8NaY1gs87o8xVQ@mail.gmail.com","threadId":"46075","inReplyTo":"20170602175455.GA30988@aiede.mtv.corp.google.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-06-02T20:29:36Z","receivedAt":"2017-06-02T20:30:02Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Jun 2, 2017 at 7:54 PM, Jonathan Nieder wrote:\n> Hi Dscho,\n>\n> Johannes Schindelin wrote:\n>> On Thu, 1 Jun 2017, Stefan Beller wrote:\n>\n>>> We had a discussion off list how much of the test suite is in bad shape,\n>>> and \"$ git grep ^index\" points out a lot of places as well.\n>>\n>> Maybe we should call out a specific month (or even a longer period) during\n>> which we try to push toward that new hash function, and focus more on\n>> those tasks (and on critical bug fixes, if any) than anything else.\n>\n> Thanks for offering. ;-)\n>\n> Here's a rough list of some useful tasks, in no particular order:\n>\n> 1. bc/object-id: This patch series continues, eliminating assumptions\n> about the size of object ids by encapsulating them in a struct.\n> One straightforward way to find code that still needs to be\n> converted is to grep for \"sha\" --- often the conversion patches\n> change function and variable names to refer to oid_ where they used\n> to use sha1_, making the stragglers easier to spot.\n>\n> 2. Hard-coded object ids in tests: As Stefan hinted, many tests beyond\n> t00* make assumptions about the exact values of object ids. That's\n> bad for maintainability for other reasons beyond the hash function\n> transition, too.\n>\n> It should be possible to suss them out by patching git's sha1\n> routine to use the ones-complement of sha1 (~sha1) instead and\n> seeing which tests fail.\n\nI just hacked this up locally. While a lot of stuff fails, it's not\nexactly an out of control garbage fire and could be churned through by\nsomeone interested. A lot of it's just lazy sha1 hardcoding for no\ngood reason where we could use a tag, or e.g. test_cmp on ls-tree\noutput without the test really caring about the hash. Things that\nreally need to test the sha1 could be guarded by some new prereq.\n\nBoth of my attempts to fuzz SHA1DCInit though resulted in some\nsegfaults, I tried both changing \"0x\" to \"~0x\" in the ihv assignment,\nand just calling SHA1DCUpdate(ctx, \"x\", 1) at the end of the function,\nnot sure why that's happening.\n\nIf someone knows offhand what I'm doing wrong here I might be\ninterested in going through this if I don't have to sift through the\nsegfaults. I.e. what's an easy hack to make all of git pretend that\n\"foo\" hashes to \"xfoo\", \"\" to \"x\" etc.\n\n> 4. When choosing a hash function, people may argue about performance.\n> It would be useful for run some benchmarks for git (running\n> the test suite, t/perf tests, etc) using a variety of hash\n> functions as input to such a discussion.\n\nTo the extent that such benchmarks matter, it seems prudent to heavily\nweigh them in favor of whatever seems to be likely to be the more\ncommon hash function going forward, since those are likely to get\nfaster through future hardware acceleration.\n\nE.g. Intel announced Goldmont last year which according to one SHA-1\nimplementation improved from 9.5 cycles per byte to 2.7 cpb[1]. They\nonly have acceleration for SHA-1 and SHA-256[2]\n\n1. https://github.com/weidai11/cryptopp/issues/139#issuecomment-264283385\n\n2. https://en.wikipedia.org/wiki/Goldmont\n"},{"id":"321467","messageId":"xmqqr2z1x5zh.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170602175455.GA30988@aiede.mtv.corp.google.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-03T00:36:02Z","receivedAt":"2017-06-03T00:36:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> 2. Hard-coded object ids in tests: As Stefan hinted, many tests beyond\n> t00* make assumptions about the exact values of object ids. That's\n> bad for maintainability for other reasons beyond the hash function\n> transition, too.\n>\n> It should be possible to suss them out by patching git's sha1\n> routine to use the ones-complement of sha1 (~sha1) instead and\n> seeing which tests fail.\n\nOne particularly nasty one is t1512-rev-parse-disambiguation that\nensures that the abbreviation and disambiguation works correctly.\nIt uses a set of objects (tags, commits, trees and blobs) whose\nobject names all begin with number of \"0\"; which will of course\nbecome useless once we change the hash function.\n\nNo matter what new hash function is chosen, we'd need a similar\ntest to ensure that disambiguation works correctly, so one of the\ntasks for hash migration is to port (not drop) this test.\n"},{"id":"321651","messageId":"alpine.DEB.2.21.1.1706070008440.171564@virtualbox","threadId":"46075","inReplyTo":"20170602175455.GA30988@aiede.mtv.corp.google.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-06T22:22:50Z","receivedAt":"2017-06-06T22:23:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonathan,\n\nOn Fri, 2 Jun 2017, Jonathan Nieder wrote:\n\n> Johannes Schindelin wrote:\n> > On Thu, 1 Jun 2017, Stefan Beller wrote:\n> \n> >> We had a discussion off list how much of the test suite is in bad shape,\n> >> and \"$ git grep ^index\" points out a lot of places as well.\n> >\n> > Maybe we should call out a specific month (or even a longer period) during\n> > which we try to push toward that new hash function, and focus more on\n> > those tasks (and on critical bug fixes, if any) than anything else.\n> \n> Thanks for offering. ;-)\n\nUndoubtedly my lack of command of the English language is to blame for\nthis misunderstanding.\n\nBy no means did I try to indicate that I am ready to accept the\nresponsibility of working toward a new hash dumped on me.\n\nWhat I wanted to suggest instead was that the current direction looks very\nunfocused to me, and that I do not see anything going forward in a\ncoherent manner. Hence my suggestion to make it public known that a\ncertain time period would be dedicated (and contributions would be highly\nencouraged) to work on replacing SHA-1 by something else.\n\nBut:\n\n1) this cannot be a one-person effort, it is too large\n\n2) it cannot even be as uncoordinated an effort as it is now, because that\nleads only to bikeshedding instead of progress\n\n3) the only person who could make that call is Junio\n\n4) we still have the problem that there is no cryptography expert among\nthose who in the Git project are listened to\n\n> How did you get the impression that their opinion had no impact? We have\n> been getting feedback about the choice of hash function both on and off\n> list from a variety of people, some indisputably security experts.\n> Sometimes the best one can do is to just listen.\n\nI did get the impression by talking at length to a cryptography expert who\nsuccessfully resisted any suggestions to get involved in the Git mailing\nlist.\n\nThere were also accounts floating around on Twitter that a certain\ncryptography expert who dared to mention already back in 2005 how\ndangerous it would be to hardcode SHA-1 into Git was essentially shown the\nfinger, and I cannot fault him for essentially saying \"I told you so\"\npublicly.\n\nIn my mind, it would have made sense to ask well-respected cryptographers\nabout their opinions and then try to figure out a consensus among them (as\nopposed to what I saw so far, a lot of enthusastic talk by developers with\nlittle standing in the cryptography community, mostly revolving around\nhash size and speed as opposed to security). And then try to implement\nthat consensus in Git. Given my recent success rate with SHA-1 related\nconcerns, I am unfortunately not the person who can bring that about.\n\nBut maybe you are.\n\nCiao,\nDscho\n"},{"id":"321653","messageId":"20170606224524.GC21733@aiede.mtv.corp.google.com","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706070008440.171564@virtualbox","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-06-06T22:45:24Z","receivedAt":"2017-06-06T22:45:34Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n> On Fri, 2 Jun 2017, Jonathan Nieder wrote:\n>> Johannes Schindelin wrote:\n\n>>> Maybe we should call out a specific month (or even a longer period) during\n>>> which we try to push toward that new hash function, and focus more on\n>>> those tasks (and on critical bug fixes, if any) than anything else.\n>>\n>> Thanks for offering. ;-)\n>\n> Undoubtedly my lack of command of the English language is to blame for\n> this misunderstanding.\n>\n> By no means did I try to indicate that I am ready to accept the\n> responsibility of working toward a new hash dumped on me.\n\nIt was a joke. More seriously, I do appreciate your questions to get\nthis discussion going.\n\n[...]\n> 3) the only person who could make that call is Junio\n\nI strongly disagree with this.\n\n> 4) we still have the problem that there is no cryptography expert among\n> those who in the Git project are listened to\n\n*shrug* I still don't know what you are suggesting here. Are you\nsaying we should find a cryptography expert to pay? Or do you have\nother specific suggestions of how to attract them?\n\n>> How did you get the impression that their opinion had no impact? We have\n>> been getting feedback about the choice of hash function both on and off\n>> list from a variety of people, some indisputably security experts.\n>> Sometimes the best one can do is to just listen.\n>\n> I did get the impression by talking at length to a cryptography expert who\n> successfully resisted any suggestions to get involved in the Git mailing\n> list.\n\nI know of other potential Git contributors that have resisted getting\ninvolved in the Git mailing list, too. I still don't know what you\nare suggesting here. Forgive me for being dense.\n\n> There were also accounts floating around on Twitter that a certain\n> cryptography expert who dared to mention already back in 2005 how\n> dangerous it would be to hardcode SHA-1 into Git was essentially shown the\n> finger, and I cannot fault him for essentially saying \"I told you so\"\n> publicly.\n\nI think there is a concrete suggestion embedded here: when discussions\ngo in an unproductive direction, my usual practice has been to keep\naway from them. This means that to a casual observer there can appear\nto be a consensus that doesn't really exist. We need to do better\nthan that: when a prominent contributor like Linus and people newer to\nthe project are emphatically dismissing the security impact of using a\nbroken hash function, others in the project need to speak up to make\nit clear that those are not the actual opinions of the project.\n\nTo put it another way: \"The standard you walk past is the standard you\naccept\". I have failed at this.\n\nIt is a very hard problem to solve, but it is worth solving.\n\n> In my mind, it would have made sense to ask well-respected cryptographers\n> about their opinions and then try to figure out a consensus among them (as\n> opposed to what I saw so far, a lot of enthusastic talk by developers with\n> little standing in the cryptography community, mostly revolving around\n> hash size and speed as opposed to security). And then try to implement\n> that consensus in Git. Given my recent success rate with SHA-1 related\n> concerns, I am unfortunately not the person who can bring that about.\n>\n> But maybe you are.\n\nI think you are being a bit dismissive of both the work done so far\nand the value of your own work.\n\nI am happy to solicit more input from security researchers, though,\nand your suggestion to do so is good advice.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"321654","messageId":"CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706070008440.171564@virtualbox","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-06T22:45:52Z","receivedAt":"2017-06-06T22:45:59Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin\n wrote:\n>> Thanks for offering. ;-)\n>\n> Undoubtedly my lack of command of the English language is to blame for\n> this misunderstanding.\n\nSometimes it is best to not be a native speaker, just fluent enough to\nget by. :)\n\n> What I wanted to suggest instead was that the current direction looks very\n> unfocused to me\n\nThat is unfortunate but reality of being a *real* community project.\nNeither you nor me (nor Junio) can command people to do things.\nThe best we can do is reject an idea going off.\n\n>, and that I do not see anything going forward in a\n> coherent manner.\n\nBut is this bad?\n\n> 1) this cannot be a one-person effort, it is too large\n\nI agree. But there are efforts by multiple people.\nSee Brians series (lots of different reviewers), also Brandon picked\nup parts of it (origin/bw/object-id). Or the design that was discussed\non list, which was lots of people participation.\n\n>\n> 2) it cannot even be as uncoordinated an effort as it is now, because that\n> leads only to bikeshedding instead of progress\n\nJonathan presented a list of things, that can be done in parallel in an\nuncoordinated effort, because that is how the project works.\n(C.f. he mentioned \"rogue agents\")\n\n> 3) the only person who could make that call is Junio\n\nOccasionally I think the same, but in fact it is not true. As said above,\nJunio has strong veto power for things going off rails, but in his role\nas a maintainer he does not coordinate people. (He occasionally asks\nthem to coordinate between themselves, though)\n\n>\n> 4) we still have the problem that there is no cryptography expert among\n> those who in the Git project are listened to\n\nI can assure you that Jonathan listened to crypto experts. It just did not\nhappen on the mailing list, which is sad regarding openness and transparency.\n\n\n5. The timeline you seem to favor would be really great for people working\non Git at $BIG_CORP, as big corps usually plan things by the quarter. So maybe\nby having a timeline (known in advance of the quarter) can convince managers\neasier.\n\n>\n>> How did you get the impression that their opinion had no impact? We have\n>> been getting feedback about the choice of hash function both on and off\n>> list from a variety of people, some indisputably security experts.\n>> Sometimes the best one can do is to just listen.\n>\n> I did get the impression by talking at length to a cryptography expert who\n> successfully resisted any suggestions to get involved in the Git mailing\n> list.\n>\n> There were also accounts floating around on Twitter that a certain\n> cryptography expert who dared to mention already back in 2005 how\n> dangerous it would be to hardcode SHA-1 into Git was essentially shown the\n> finger, and I cannot fault him for essentially saying \"I told you so\"\n> publicly.\n\nHeh. The community between 2005 and now has changed. (I was not there\nfor example. ;-) ) So let's hope the community changes for the better.\n\n> In my mind, it would have made sense to ask well-respected cryptographers\n> about their opinions and then try to figure out a consensus among them (as\n> opposed to what I saw so far, a lot of enthusastic talk by developers with\n> little standing in the cryptography community, mostly revolving around\n> hash size and speed as opposed to security). And then try to implement\n> that consensus in Git.\n\nSounds good to me. That is why I personally think point (4) from\nJonathans list above over-emphasizes performance/size over security.\n\nOn the other hand if we find a smart way now, then this hash function\ntransition will open the road to switching the hash function down the road\nonce again with less or even no penalty if we make mistakes in choosing\nyet another bad hash function now.\n\n> Given my recent success rate with SHA-1 related\n> concerns, I am unfortunately not the person who can bring that about.\n>\n> But maybe you are.\n>\n> Ciao,\n> Dscho\n\nThanks for bringing the discussion back to life,\nStefan\n"},{"id":"321655","messageId":"20170606225249.GD21733@aiede.mtv.corp.google.com","threadId":"46075","inReplyTo":"CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-06-06T22:52:49Z","receivedAt":"2017-06-06T22:53:01Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stefan Beller wrote:\n> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin\n> wrote:\n\n>> In my mind, it would have made sense to ask well-respected cryptographers\n>> about their opinions and then try to figure out a consensus among them (as\n>> opposed to what I saw so far, a lot of enthusastic talk by developers with\n>> little standing in the cryptography community, mostly revolving around\n>> hash size and speed as opposed to security). And then try to implement\n>> that consensus in Git.\n>\n> Sounds good to me. That is why I personally think point (4) from\n> Jonathans list above over-emphasizes performance/size over security.\n\nThe very least the only kind of replies my example task (4) led to\nwere of this kind, so you can get a clear sense of whether the\ncommunity values performance over security. :)\n\nI happen to think that performance and security both matter and are\nrelated (since if performance regresses enough, then people end up\nusing the faster but insecure thing). This has shown up in the\nhistory of SSL, for example. But I am very happy to see people\nfocusing more on the security properties than the performance\nproperties --- that is a correct prioritization.\n\nJonathan\n"},{"id":"321657","messageId":"CAJZjrdX-Xfe=JUHtv69m9KRJrd5xAZmfECwYLH_fy-gjEBZhYw@mail.gmail.com","threadId":"46075","inReplyTo":"CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-06-07T00:34:33Z","receivedAt":"2017-06-07T00:35:20Z","isPatch":true,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Tue, Jun 6, 2017 at 6:45 PM, Stefan Beller wrote:\n> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin\n> wrote:\n>>\n>> 4) we still have the problem that there is no cryptography expert among\n>> those who in the Git project are listened to\n>\n> I can assure you that Jonathan listened to crypto experts. It just did not\n> happen on the mailing list, which is sad regarding openness and transparency.\n\nIn the interest of openness and transparency, perhaps a blue doc\nshould be put together to outline and document the hash function that\nsucceeds SHA1, and the rationales for doing so? It would, ideally,\ncite (preferably by including, and not just linking to) any\ndiscussions with crypto experts that have chimed in off-list (given\nsaid experts' consent for any such communication to be publicized,\nnaturally).\n\nIf I'm not mistaken, the only such doc behind the transition right now\nis the Git hash function transition document, which covers the\ntechnical barriers to replacing SHA1, but not why we might choose X to\nreplace SHA1.\n"},{"id":"321658","messageId":"xmqqwp8o7gdc.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170606224524.GC21733@aiede.mtv.corp.google.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-07T01:09:51Z","receivedAt":"2017-06-07T01:10:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n>> 3) the only person who could make that call is Junio\n>\n> I strongly disagree with this.\n\nIf it helps, I _can_ make any set of declarations to make it sound\nmore official, e.g. (the remainder of) June is the \"make sure our\ntests are ready\" month where we try to eradiate uchar[20] by\nadvancing the object-id effort, replace EMPTY_TREE_SHA1_HEX and\nfriends with EMPTY_TREE_OID_HEX, add a build-time configuration that\nallows us to build a Git binary that uses a phony hash e.g. ~sha1\ntruncated to 16 bytes, and build Git with such a configuration and\nthen run tests, and we concentrate on this effort without adding new\nthings until we make the tests pass.\n\nAnd make similar declarations for the remainder of the year.\n\nBut the actual input for formulating what each step does and the\ntimeline we aim for needs to come from the list wisdom; it won't\nhave much impact if the project's official declaration is not\nfollowed-thru, and a unilateral declaration that is pulled out of\nthin-air likely will not be.\n\n> I am happy to solicit more input from security researchers, though,\n> and your suggestion to do so is good advice.\n\nOne good thing is that we can prepare the framework to adopt a new\nhash before knowing what the exact hash function is; crypto-minded\nfolks can work on the hash selection in parallel without waiting for\nthe framework to become ready. And I do agree with Dscho that\nhaving crypto experts would be very helpful for the latter.\n"},{"id":"321659","messageId":"20170607021805.11849-1-sbeller@google.com","threadId":"46075","inReplyTo":"xmqqwp8o7gdc.fsf@gitster.mtv.corp.google.com","subject":"[PATCH] t4005: modernize style and drop hard coded sha1","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-07T02:18:05Z","receivedAt":"2017-06-07T02:18:15Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Use modern style in the test t4005. Remove hard coded sha1 values.\nCombine test prep work and the actual test. Rename the first\ntest to contain the word \"setup\".\n\nSigned-off-by: Stefan Beller \n---\n\nJunio wrote:\n> If it helps, I _can_ make any set of declarations to make it sound\n> more official, e.g. (the remainder of) June is the \"make sure our\n> tests are ready\" \n\nIf it helps, I can write code for that. :)\n\nDo get a good grasp on which tests need to be fixed, I changed the seed\nvalue for the sha1 computation and then run the test suite. There are a lot\nof tests passing for this, but also quite a few failing. Then I picked t4005\nrandomly to start with. This patch works even with a crippled hash function\nas we use hash-object to get the object id.\n\nThanks,\nStefan\n\n t/t4005-diff-rename-2.sh | 95 ++++++++++++++++++++++--------------------------\n 1 file changed, 43 insertions(+), 52 deletions(-)\n\ndiff --git a/t/t4005-diff-rename-2.sh b/t/t4005-diff-rename-2.sh\nindex 135addbfbd..f542d2929d 100755\n--- a/t/t4005-diff-rename-2.sh\n+++ b/t/t4005-diff-rename-2.sh\n@@ -3,84 +3,75 @@\n # Copyright (c) 2005 Junio C Hamano\n #\n \n-test_description='Same rename detection as t4003 but testing diff-raw.\n+test_description='Same rename detection as t4003 but testing diff-raw.'\n \n-'\n . ./test-lib.sh\n . \"$TEST_DIRECTORY\"/diff-lib.sh ;# test-lib chdir's into trash\n \n-test_expect_success \\\n- 'prepare reference tree' \\\n- 'cat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n- echo frotz >rezrov &&\n- git update-index --add COPYING rezrov &&\n- tree=$(git write-tree) &&\n- echo $tree'\n-\n-test_expect_success \\\n- 'prepare work tree' \\\n- 'sed -e 's/HOWEVER/However/' COPYING.1 &&\n- sed -e 's/GPL/G.P.L/g' COPYING.2 &&\n- rm -f COPYING &&\n- git update-index --add --remove COPYING COPYING.?'\n+test_expect_success 'setup reference tree' '\n+\tcat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n+\techo frotz >rezrov &&\n+\tgit update-index --add COPYING rezrov &&\n+\ttree=$(git write-tree) &&\n+\techo $tree &&\n+\tsed -e 's/HOWEVER/However/' COPYING.1 &&\n+\tsed -e 's/GPL/G.P.L/g' COPYING.2 &&\n+\torigoid=$(git hash-object COPYING) &&\n+\toid1=$(git hash-object COPYING.1) &&\n+\toid2=$(git hash-object COPYING.2)\n+'\n \n+################################################################\n # tree has COPYING and rezrov. work tree has COPYING.1 and COPYING.2,\n # both are slightly edited, and unchanged rezrov. We say COPYING.1\n # and COPYING.2 are based on COPYING, and do not say anything about\n # rezrov.\n \n-git diff-index -C $tree >current\n-\n-cat >expected <<\\EOF\n-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 R1234\tCOPYING\tCOPYING.2\n-EOF\n+test_expect_success 'validate output from rename/copy detection (#1)' '\n+\trm -f COPYING &&\n+\tgit update-index --add --remove COPYING COPYING.? &&\n \n-test_expect_success \\\n- 'validate output from rename/copy detection (#1)' \\\n- 'compare_diff_raw current expected'\n+\tcat <<-EOF >expected &&\n+\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n+\t:100644 100644 $origoid $oid2 R1234\tCOPYING\tCOPYING.2\n+\tEOF\n+\tgit diff-index -C $tree >current &&\n+\tcompare_diff_raw expected current\n+'\n \n ################################################################\n-\n-test_expect_success \\\n- 'prepare work tree again' \\\n- 'mv COPYING.2 COPYING &&\n- git update-index --add --remove COPYING COPYING.1 COPYING.2'\n-\n # tree has COPYING and rezrov. work tree has COPYING and COPYING.1,\n # both are slightly edited, and unchanged rezrov. We say COPYING.1\n # is based on COPYING and COPYING is still there, and do not say anything\n # about rezrov.\n \n-git diff-index -C $tree >current\n-cat >expected <<\\EOF\n-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 M\tCOPYING\n-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n-EOF\n+test_expect_success 'validate output from rename/copy detection (#2)' '\n+\tmv COPYING.2 COPYING &&\n+\tgit update-index --add --remove COPYING COPYING.1 COPYING.2 &&\n \n-test_expect_success \\\n- 'validate output from rename/copy detection (#2)' \\\n- 'compare_diff_raw current expected'\n+\tcat <<-EOF >expected &&\n+\t:100644 100644 $origoid $oid2 M\tCOPYING\n+\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n+\tEOF\n+\tgit diff-index -C $tree >current &&\n+\tcompare_diff_raw current expected\n+'\n \n ################################################################\n-\n # tree has COPYING and rezrov. work tree has the same COPYING and\n # copy-edited COPYING.1, and unchanged rezrov. We should not say\n # anything about rezrov or COPYING, since the revised again diff-raw\n # nows how to say Copy.\n \n-test_expect_success \\\n- 'prepare work tree once again' \\\n- 'cat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n- git update-index --add --remove COPYING COPYING.1'\n-\n-git diff-index -C --find-copies-harder $tree >current\n-cat >expected <<\\EOF\n-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n-EOF\n+test_expect_success 'validate output from rename/copy detection (#3)' '\n+\tcat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n+\tgit update-index --add --remove COPYING COPYING.1 &&\n \n-test_expect_success \\\n- 'validate output from rename/copy detection (#3)' \\\n- 'compare_diff_raw current expected'\n+\tcat <<-EOF >expected &&\n+\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n+\tEOF\n+\tgit diff-index -C --find-copies-harder $tree >current &&\n+\tcompare_diff_raw current expected\n+'\n \n test_done\n-- \n2.13.0.17.gf3d7728391\n\n"},{"id":"321673","messageId":"5309bbe7-edd8-0c34-82ff-c3162d7d9e66@talktalk.net","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706011329350.3610@virtualbox","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-07T10:47:02Z","receivedAt":"2017-06-07T10:47:11Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Johannes\n\nThanks for your feedback\nOn 01/06/17 13:56, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> On Wed, 31 May 2017, Phillip Wood wrote:\n> \n>> From: Phillip Wood \n>>\n>> Check the console output when using --autostash and the stash applies\n>> cleanly is what we expect. To avoid this test depending on commit and\n>> stash hashes it uses sed to replace them with XXX. The sed script also\n>> replaces carriage returns in the output with '\\r' to avoid embedded\n>> '^M's in the expected output files. Unfortunately this means we still\n>> end up with an embedded '^M' in the sed script which may not be\n>> preserved when sending this. The last line of the sed script should be\n>> +s/^M/\\\\r/g\n> \n> Like Junio pointed out, this sed script would not be portable. To\n> elaborate: there are two major variants of sed out there, GNU sed and BSD\n> sed. Typically GNU sed allows a little more powerful instructions, e.g. \\t\n> and \\r.\n\nI'm confused by this as my script does not use the escape sequence \"\\r\"\nout of portability concerns. It has a literal carriage return as you get\nfrom typing Ctrl-Q Ctrl-M in emacs or Ctrl-V Ctrl-M in bash which I\nthink should be portable and replaces the carriage returns in git's\noutput with the literal string '\\r'. I did this so that the expected\nfiles don't have control characters in them that mess up the display\nwhen you cat them or read them in an email client\n\n> But we should simply take a step back and ask why test_cmp is not enough\n> to ignore the CRs in the output?\n> \n> Also, about the commit IDs. As long as the tests are consistent (i.e. they\n> use test_commit rather than plain `git commit`, or at least call\n> `test_tick` beforehand), the commit IDs should actually be identical\n> between runs and not depend on the time of day or the date.\n> \n> The only exception to that rule is when some previous test cases call\n> `test_commit` but are guarded behind some prereq and may not be executed\n> at all. In that case, the precise commit IDs depend on the particular set\n> of active prereqs.\n\nThe other exceptions are when the commit hash algorithm changes or the\ncontents of the commits changes because of some update to the test\nscript. That's why I didn't want to rely on matching fixed SHA1s\n\n> \n> But as far as I can tell, t3420 does not have any test cases guarded by\n> prereqs.\n> \n> Taking an additional step back, I wonder whether we have to hard-code the\n> commit IDs (or XXX) to begin with. Why not generate the `expect` files\n> with the information at hand? We can simply ask `git rev-parse --short`.\n> \n> For the stash's commit ID, there is no record in the ref space, of course\n> (because it was created with `git stash create`). But I think in this\n> case, it is legitimate to simply grep the output.\n\nThat's a good approach to handling the stash hash if we want to generate\nthe expected files from the test script\n\n> That way, the test would be precise and resilient.\n> \n> So for example instead of adding the t/t3420/expected-success-am verbatim,\n> you could generate the output via\n> \n> \tcat >expect <<-EOF\n> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\\\$\" output)\n> \tHEAD is now at $(git rev-parse --short HEAD~2) third commit\n> \tFirst, rewinding head to replay your work on top of it...\n> \tApplying: second commit\n> \tApplying: third commit\n> \tApplied autostash.\n> \tEOF\n\nThis approach works well for the cases where there aren't control\ncharacters embedded in git's output, but for the interactive tests there\nare so we'd end up with control characters in the test script which I\nwanted to avoid or doing $(printf '\\r'). I steered clear of generating\nthe expected file in the test as i) it was more work (both for me\n(rebase --merge has a few commit hashes in it's output) and when the\nscript is running) and ii) it's a bit messy to implement given the way\nthe tests are structured in a helper function that's called with a\nparameter indicating the type of rebase to test.\n\nI can go ahead with generating the expected files from the script if you\nreally want but I wonder if changing the test to generate the sed script\nwith printf as below might be a simpler way to mitigate the carriage\nreturn problem, though it would be less strict than generating the real\nhashes with rev-parse.\n\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -189,6 +189,16 @@ test_expect_success \"rebase: noop rebase\" '\n \tgit checkout feature-branch\n '\n\n+test_expect_sucess 'rebase: create sed script to sanitize output' '\n+\tprintf \"\\\n+s/^\\(Created autostash: \\)[0-9a-f]\\{6,\\}$/\\1XXX/\n+s/^\\(HEAD is now at \\)[0-9a-f]\\{6,\\}\\( .* commit\\)$/\\1XXX\\2/\n+s/^[0-9a-f]\\{6,\\}\\( .* commit\\)$/XXX\\1/\n+s/\\(detached HEAD \\)[0-9a-f]\\{6,\\}/\\1XXX/\n+s/\\(could not apply \\)[0-9a-f]\\{6,\\}/\\1XXX/g\n+s/\\\\r/\\\\r/g\" >$TEST_DIRECTORY/t4320/remove-ids.sed\n+'\n+\n\nLet me know what you think,\n\nBest Wishes\n\nPhillip\n\n"},{"id":"321677","messageId":"alpine.DEB.2.21.1.1706071520280.171564@virtualbox","threadId":"46075","inReplyTo":"CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-07T14:47:05Z","receivedAt":"2017-06-07T15:03:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Tue, 6 Jun 2017, Stefan Beller wrote:\n\n> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin\n> wrote:\n>\n> > 3) the only person who could make that call is Junio\n> \n> Occasionally I think the same, but in fact it is not true.\n\nAgain my poor English skillz make sure I get misunderstood. So bear with\nme, please, and let me try again.\n\nThe current What's cooking mails are full of stuff other than the\ntransition from SHA-1 to a new function. In fact, every once in a while I\nsee brian carlson's patch series with the remark \"Needs review\" while\nother patch series get reviewed even by Junio.\n\nIn my mind, this sends a message.\n\nIf, hypothetically, a couple of What's cooking mails would have in their\nheader some language to the extent that we need to focus on transitioning\naway from SHA-1, and maybe even have the promise that Junio would not\nreview other patch series as long as there are patches to review that\nprepare the tests for the transition, that convert more 20 and 40\nconstants, that convert more users to object_ids (and maybe strongly\nencourage to coordinate with brian so as not to trip over each others'\ntoes), to implement a command to convert a SHA-1 based repository to a\nrepository based on a different hash, to implement caching of legacy SHA-1\n<=> new hash mapping, then that would send a wholly different message.\n\nAnd in my mind, if anybody else than Junio sent this message, it would\nsound ludicrous. For example, if I sent a mail to that extent, I would\nfind it ridiculous myself, in particular since I am a very unprolific\nreviewer, and the promise to focus on favoring reviews of SHA-1 transition\nrelated patches would sound very unsincere from somebody like me.\n\n> As said above, Junio has strong veto power for things going off rails,\n> but in his role as a maintainer he does not coordinate people. (He\n> occasionally asks them to coordinate between themselves, though)\n\nI never had in mind that Junio would coordinate people or distribute\ntasks.\n\nInstead, I had in mind that a certain time period could be called out as\nfocusing on that pretty important direction.\n\nThat would be mostly symbolic, of course. And encouraging. In a positive\nway. With a direction.\n\n> > 4) we still have the problem that there is no cryptography expert among\n> > those who in the Git project are listened to\n> \n> I can assure you that Jonathan listened to crypto experts. It just did\n> not happen on the mailing list, which is sad regarding openness and\n> transparency.\n\nTrue. Same goes for me, of course. I just felt pretty uncomfortable\nsharing the contents of my private conversation publicly, when I tried\nvery hard to convince my conversation partner to join the discussion on\nthis mailing list, and they refused.\n\nThe gist of it was: SHA-256 should be preferred to SHA3-256 because we\nwill soon have good hardware support (and performance is really, really\nimportant when you need to work on the largest Git repository on this\nplanet). And if there is no consensus about that, BLAKE should be\nconsidered over other algorithms because it has been studied pretty well.\n\nCiao,\nDscho\n> \n> \n> 5. The timeline you seem to favor would be really great for people working\n> on Git at $BIG_CORP, as big corps usually plan things by the quarter. So maybe\n> by having a timeline (known in advance of the quarter) can convince managers\n> easier.\n> \n> >\n> >> How did you get the impression that their opinion had no impact? We have\n> >> been getting feedback about the choice of hash function both on and off\n> >> list from a variety of people, some indisputably security experts.\n> >> Sometimes the best one can do is to just listen.\n> >\n> > I did get the impression by talking at length to a cryptography expert who\n> > successfully resisted any suggestions to get involved in the Git mailing\n> > list.\n> >\n> > There were also accounts floating around on Twitter that a certain\n> > cryptography expert who dared to mention already back in 2005 how\n> > dangerous it would be to hardcode SHA-1 into Git was essentially shown the\n> > finger, and I cannot fault him for essentially saying \"I told you so\"\n> > publicly.\n> \n> Heh. The community between 2005 and now has changed. (I was not there\n> for example. ;-) ) So let's hope the community changes for the better.\n> \n> > In my mind, it would have made sense to ask well-respected cryptographers\n> > about their opinions and then try to figure out a consensus among them (as\n> > opposed to what I saw so far, a lot of enthusastic talk by developers with\n> > little standing in the cryptography community, mostly revolving around\n> > hash size and speed as opposed to security). And then try to implement\n> > that consensus in Git.\n> \n> Sounds good to me. That is why I personally think point (4) from\n> Jonathans list above over-emphasizes performance/size over security.\n> \n> On the other hand if we find a smart way now, then this hash function\n> transition will open the road to switching the hash function down the road\n> once again with less or even no penalty if we make mistakes in choosing\n> yet another bad hash function now.\n> \n> > Given my recent success rate with SHA-1 related\n> > concerns, I am unfortunately not the person who can bring that about.\n> >\n> > But maybe you are.\n> >\n> > Ciao,\n> > Dscho\n> \n> Thanks for bringing the discussion back to life,\n> Stefan\n> \n"},{"id":"321690","messageId":"CAGZ79ka5VnfvidpsWCe5py6uW2Yp0y9gHfdZt+aZSdyfEi8Fsg@mail.gmail.com","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706071520280.171564@virtualbox","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-07T16:53:11Z","receivedAt":"2017-06-07T16:53:18Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jun 7, 2017 at 7:47 AM, Johannes Schindelin\n wrote:\n> Hi Stefan,\n>\n> On Tue, 6 Jun 2017, Stefan Beller wrote:\n>\n>> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin\n>> wrote:\n>>\n>> > 3) the only person who could make that call is Junio\n>>\n>> Occasionally I think the same, but in fact it is not true.\n>\n> Again my poor English skillz make sure I get misunderstood. So bear with\n> me, please, and let me try again.\n\nI don't think it is a language thing, but a matter of perspective.\n\n>\n> The current What's cooking mails are full of stuff other than the\n> transition from SHA-1 to a new function.\n\nTrue, but there is also\n\n * bw/object-id (2017-06-05) 33 commits\n ...\n\n Conversion from uchar[20] to struct object_id continues.\n\n Will merge to 'next'.\n\n\n> In fact, every once in a while I\n> see brian carlson's patch series with the remark \"Needs review\" while\n> other patch series get reviewed even by Junio.\n\nSo are you trying to impose priorities on what Junio has to review?\n(It sounds like so, but maybe you are just stating an observation,\nand a conclusion with an actionable item comes next)\n\nSometimes I disagree with what Junio does and in which order, too.\nBut he has more experience in how to guide a successful community,\nso I respect what he does even if I would have done it differently (such\nas a different order).\n\n>\n> In my mind, this sends a message.\n\nIn the simplest form the message could be understood as a call for help\nto review the patches Brian sent.\n\nAnd the fact that YOU are not reviewing the patches, tells me that\nyou have more important things to do, such as running a fork of Git.\n\nIn my perception the conversion is picking up speed. It used to be Brian\nwho decided to start this years ago as a one-man show, but now we\nhave multiple people working on it\n* Brian sending out more patches, as more review happens:\nhttps://public-inbox.org/git/5973919a-e282-a02e-9b04-d313c77e250d@google.com/\nhttps://public-inbox.org/git/20170509221322.GA106700@google.com/\n* Brandon picking up one part of the conversion series (mentioned before, see\ncurrent cooking email)\n* A potential migration plan has been made\n \"Git hash function transition\" (https://goo.gl/gh2Mzc).\n See the note atop the document \"Note: this draft is somewhat out\n of date and is being reworked (in particular to use a different hash\nfunction).\n See public-inbox.org/git for more current discussion.\"\n* There are not a lot of patches, which do not have written\n \"SHA1 CONVERISON\" all over their face. (This one has, I made it last night\n as a one off response to this thread:\nhttps://public-inbox.org/git/20170607021805.11849-1-sbeller@google.com/)\n\n>\n> If, hypothetically, a couple of What's cooking mails would have in their\n> header some language to the extent that we need to focus on transitioning\n> away from SHA-1, and maybe even have the promise that Junio would not\n> review other patch series as long as there are patches to review that\n> prepare the tests for the transition, that convert more 20 and 40\n> constants, that convert more users to object_ids (and maybe strongly\n> encourage to coordinate with brian so as not to trip over each others'\n> toes), to implement a command to convert a SHA-1 based repository to a\n> repository based on a different hash, to implement caching of legacy SHA-1\n> <=> new hash mapping, then that would send a wholly different message.\n\nThat message sent there would be \"Junio thinks the SHA1 conversion is\nthe most important thing now, so he does the work (the work a maintainer\ndoes to guide the project)\".\n\nYou could send the same message \"Johannes thinks the SHA1 conversion\nis the most important thing and do the work (Johannes being a well respected\ncontributor would send patches, and that would attract a lot of\nreviews for sure.\n-- I don't mean this snarky, please don't read any snark in this.)\n\n> And in my mind, if anybody else than Junio sent this message, it would\n> sound ludicrous.\n\nYes I have seen a couple of these messages (unrelated topics).\n\"Git should do X. Git should not do Y. k, thx bye!\" and I ignored them,\nbecause these one-offs do not convince me to invest my own time\nin it to produce a reasonable ROI.\n\nIf there are patches attached, it is not ludicrous any more as the \"proof\nof work done\" shows that the voice raised is more than just hot talk, but\nactual a genuine interest in moving things towards the right direction.\n\nAnother big one: \"Move Git away from global state all over the place\".\nIf you think about all subsystems, it may even reach the order of\nmagnitude to the sha1 conversion, but the way the message was sent\nit did not seem ludicrous to me:\nhttps://public-inbox.org/git/20170530171217.GB2798@google.com/\n\nOr the other big project \"Protocol v2, that scales and serves large\nrepos well (number of refs, large binary files omitted, refs in wants\nand so on)\" took a different approach, and mostly discussed design\n(I recall emails both from Microsoft as well as Google discussing the\ndesign, most of them having RFC patches attached, such that it very\nmuch looked like \"proof of work done, so it is not ludicrous\")\n\n> For example, if I sent a mail to that extent, I would\n> find it ridiculous myself, in particular since I am a very unprolific\n> reviewer, and the promise to focus on favoring reviews of SHA-1 transition\n> related patches would sound very unsincere from somebody like me.\n\nIf you were to actually follow through after such an announcement,\nand in fact review the sha1 conversion patches thoroughly and in a timely\nmanner, I would think such a call up front would be well received.\n\nI thought about doing that myself, but I dread my future commitment.\nSpecifically as my $DAY_JOBs wants me to work on submodules\ninstead of the sha1 conversion. (\"Submodules are more important\nthan the SHA1 conversion [for me] \", if I were to trust the infinite wisdom\nof our management process. )\n\n\n>\n>> As said above, Junio has strong veto power for things going off rails,\n>> but in his role as a maintainer he does not coordinate people. (He\n>> occasionally asks them to coordinate between themselves, though)\n>\n> I never had in mind that Junio would coordinate people or distribute\n> tasks.\n\nCoordinate is a strong word here. Most recent observed examples:\nhttps://public-inbox.org/git/xmqq60gpfvqj.fsf@gitster.mtv.corp.google.com/\n(My patch series conflicted with Ævars series, so we had to figure\nout how to fix it)\n\nhttps://public-inbox.org/git/20170602182215.GA57260@google.com/\n(Aforementioned object id conversion series having merge conflicts)\n\nNote that this is only about coordination \"You should talk to person Y\nso we can figure out how to make these 2 patches work well together,\nnot about distributing tasks, as in \"You must do X\".\n\n> Instead, I had in mind that a certain time period could be called out as\n> focusing on that pretty important direction.\n\nAs remarked in an earlier email, if such a thing is called out, I would very\nmuch prefer it in the next quarter, as then I can convince my manager to\nhave more time following such a goal. Otherwise *I* would ignore it.\nThe community at large may be different and jump on it like crazy.\n\n> That would be mostly symbolic, of course. And encouraging. In a positive\n> way. With a direction.\n\nSo you want a project roadmap?\n\nAs hinted at before the best would be to lead a good example here\nand show *your* roadmap such that others see how valuable of a tool\nit is to have a roadmap in the open.\n\n>> > 4) we still have the problem that there is no cryptography expert among\n>> > those who in the Git project are listened to\n>>\n>> I can assure you that Jonathan listened to crypto experts. It just did\n>> not happen on the mailing list, which is sad regarding openness and\n>> transparency.\n>\n> True. Same goes for me, of course. I just felt pretty uncomfortable\n> sharing the contents of my private conversation publicly, when I tried\n> very hard to convince my conversation partner to join the discussion on\n> this mailing list, and they refused.\n>\n> The gist of it was: SHA-256 should be preferred to SHA3-256 because we\n> will soon have good hardware support (and performance is really, really\n> important when you need to work on the largest Git repository on this\n> planet). And if there is no consensus about that, BLAKE should be\n> considered over other algorithms because it has been studied pretty well.\n\nBLAKE is what we're currently leaning on. (we=authors of \"Git hash function\ntransition\"; Leaning in the sense: If nobody ever speaks up until all work is\ndone, we'd just go with that. As soon as someone comes up with any\nreasonable argument either publicly or privately on why other hashes are\nbetter, we're easily persuaded to go with that)\n\n> Again my poor English skillz make sure I get misunderstood. So bear with\n> me, please, and let me try again.\n\nSame for me, if I misunderstood you please point out.\n\ntl;dr: Discussions are nice, but someone has to do the actual work, too.\n\nThanks,\nStefan\n"},{"id":"321693","messageId":"20170607173959.GA110638@google.com","threadId":"46075","inReplyTo":"20170607021805.11849-1-sbeller@google.com","subject":"Re: [PATCH] t4005: modernize style and drop hard coded sha1","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-06-07T17:39:59Z","receivedAt":"2017-06-07T17:40:07Z","isPatch":true,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 06/06, Stefan Beller wrote:\n> Use modern style in the test t4005. Remove hard coded sha1 values.\n> Combine test prep work and the actual test. Rename the first\n> test to contain the word \"setup\".\n> \n> Signed-off-by: Stefan Beller \n> ---\n> \n> Junio wrote:\n> > If it helps, I _can_ make any set of declarations to make it sound\n> > more official, e.g. (the remainder of) June is the \"make sure our\n> > tests are ready\" \n> \n> If it helps, I can write code for that. :)\n> \n> Do get a good grasp on which tests need to be fixed, I changed the seed\n> value for the sha1 computation and then run the test suite. There are a lot\n> of tests passing for this, but also quite a few failing. Then I picked t4005\n> randomly to start with. This patch works even with a crippled hash function\n> as we use hash-object to get the object id.\n> \n> Thanks,\n> Stefan\n> \n> t/t4005-diff-rename-2.sh | 95 ++++++++++++++++++++++--------------------------\n> 1 file changed, 43 insertions(+), 52 deletions(-)\n> \n> diff --git a/t/t4005-diff-rename-2.sh b/t/t4005-diff-rename-2.sh\n> index 135addbfbd..f542d2929d 100755\n> --- a/t/t4005-diff-rename-2.sh\n> +++ b/t/t4005-diff-rename-2.sh\n> @@ -3,84 +3,75 @@\n> # Copyright (c) 2005 Junio C Hamano\n> #\n> \n> -test_description='Same rename detection as t4003 but testing diff-raw.\n> +test_description='Same rename detection as t4003 but testing diff-raw.'\n> \n> -'\n> . ./test-lib.sh\n> . \"$TEST_DIRECTORY\"/diff-lib.sh ;# test-lib chdir's into trash\n> \n> -test_expect_success \\\n> - 'prepare reference tree' \\\n> - 'cat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n> - echo frotz >rezrov &&\n> - git update-index --add COPYING rezrov &&\n> - tree=$(git write-tree) &&\n> - echo $tree'\n> -\n> -test_expect_success \\\n> - 'prepare work tree' \\\n> - 'sed -e 's/HOWEVER/However/' COPYING.1 &&\n> - sed -e 's/GPL/G.P.L/g' COPYING.2 &&\n> - rm -f COPYING &&\n> - git update-index --add --remove COPYING COPYING.?'\n> +test_expect_success 'setup reference tree' '\n> +\tcat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n> +\techo frotz >rezrov &&\n> +\tgit update-index --add COPYING rezrov &&\n> +\ttree=$(git write-tree) &&\n> +\techo $tree &&\n> +\tsed -e 's/HOWEVER/However/' COPYING.1 &&\n> +\tsed -e 's/GPL/G.P.L/g' COPYING.2 &&\n> +\torigoid=$(git hash-object COPYING) &&\n> +\toid1=$(git hash-object COPYING.1) &&\n> +\toid2=$(git hash-object COPYING.2)\n> +'\n\nThis conversation looks good to me. The only thing that made me scratch\nmy head a bit were the shell variables origoid, oid1, and oid2. It was\njust slightly confusing figuring out where they came from in the tests\nbelow before I noticed they were initialized up here.\n\n> \n> +################################################################\n> # tree has COPYING and rezrov. work tree has COPYING.1 and COPYING.2,\n> # both are slightly edited, and unchanged rezrov. We say COPYING.1\n> # and COPYING.2 are based on COPYING, and do not say anything about\n> # rezrov.\n> \n> -git diff-index -C $tree >current\n> -\n> -cat >expected <<\\EOF\n> -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n> -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 R1234\tCOPYING\tCOPYING.2\n> -EOF\n> +test_expect_success 'validate output from rename/copy detection (#1)' '\n> +\trm -f COPYING &&\n> +\tgit update-index --add --remove COPYING COPYING.? &&\n> \n> -test_expect_success \\\n> - 'validate output from rename/copy detection (#1)' \\\n> - 'compare_diff_raw current expected'\n> +\tcat <<-EOF >expected &&\n> +\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n> +\t:100644 100644 $origoid $oid2 R1234\tCOPYING\tCOPYING.2\n> +\tEOF\n> +\tgit diff-index -C $tree >current &&\n> +\tcompare_diff_raw expected current\n> +'\n> \n> ################################################################\n> -\n> -test_expect_success \\\n> - 'prepare work tree again' \\\n> - 'mv COPYING.2 COPYING &&\n> - git update-index --add --remove COPYING COPYING.1 COPYING.2'\n> -\n> # tree has COPYING and rezrov. work tree has COPYING and COPYING.1,\n> # both are slightly edited, and unchanged rezrov. We say COPYING.1\n> # is based on COPYING and COPYING is still there, and do not say anything\n> # about rezrov.\n> \n> -git diff-index -C $tree >current\n> -cat >expected <<\\EOF\n> -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 M\tCOPYING\n> -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n> -EOF\n> +test_expect_success 'validate output from rename/copy detection (#2)' '\n> +\tmv COPYING.2 COPYING &&\n> +\tgit update-index --add --remove COPYING COPYING.1 COPYING.2 &&\n> \n> -test_expect_success \\\n> - 'validate output from rename/copy detection (#2)' \\\n> - 'compare_diff_raw current expected'\n> +\tcat <<-EOF >expected &&\n> +\t:100644 100644 $origoid $oid2 M\tCOPYING\n> +\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n> +\tEOF\n> +\tgit diff-index -C $tree >current &&\n> +\tcompare_diff_raw current expected\n> +'\n> \n> ################################################################\n> -\n> # tree has COPYING and rezrov. work tree has the same COPYING and\n> # copy-edited COPYING.1, and unchanged rezrov. We should not say\n> # anything about rezrov or COPYING, since the revised again diff-raw\n> # nows how to say Copy.\n> \n> -test_expect_success \\\n> - 'prepare work tree once again' \\\n> - 'cat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n> - git update-index --add --remove COPYING COPYING.1'\n> -\n> -git diff-index -C --find-copies-harder $tree >current\n> -cat >expected <<\\EOF\n> -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234\tCOPYING\tCOPYING.1\n> -EOF\n> +test_expect_success 'validate output from rename/copy detection (#3)' '\n> +\tcat \"$TEST_DIRECTORY\"/diff-lib/COPYING >COPYING &&\n> +\tgit update-index --add --remove COPYING COPYING.1 &&\n> \n> -test_expect_success \\\n> - 'validate output from rename/copy detection (#3)' \\\n> - 'compare_diff_raw current expected'\n> +\tcat <<-EOF >expected &&\n> +\t:100644 100644 $origoid $oid1 C1234\tCOPYING\tCOPYING.1\n> +\tEOF\n> +\tgit diff-index -C --find-copies-harder $tree >current &&\n> +\tcompare_diff_raw current expected\n> +'\n> \n> test_done\n> -- \n> 2.13.0.17.gf3d7728391\n> \n\n-- \nBrandon Williams\n"},{"id":"321840","messageId":"xmqqr2yt5d4g.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"5309bbe7-edd8-0c34-82ff-c3162d7d9e66@talktalk.net","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-09T16:39:43Z","receivedAt":"2017-06-09T16:39:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> I'm confused by this as my script does not use the escape sequence \"\\r\"\n> out of portability concerns. It has a literal carriage return as you get\n> from typing Ctrl-Q Ctrl-M in emacs or Ctrl-V Ctrl-M in bash ...\n\nI think the worry is that some implementations of sed may be unhappy\nto see these raw control characters in the sed script.\n"},{"id":"322221","messageId":"699c6d43-4c1b-d3c2-3b01-8925f5c21511@talktalk.net","threadId":"46075","inReplyTo":"xmqqr2yt5d4g.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-14T10:18:10Z","receivedAt":"2017-06-14T10:18:17Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 09/06/17 17:39, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>> I'm confused by this as my script does not use the escape sequence \"\\r\"\n>> out of portability concerns. It has a literal carriage return as you get\n>> from typing Ctrl-Q Ctrl-M in emacs or Ctrl-V Ctrl-M in bash ...\n> \n> I think the worry is that some implementations of sed may be unhappy\n> to see these raw control characters in the sed script.\n> \n\nAh, I'd misunderstood the problem, thanks for taking the time to point\nthat out. I'll redo the tests as Johannes suggested\n\nThanks\n\nPhillip\n"},{"id":"322225","messageId":"20170614102427.5220-1-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-1-phillip.wood@talktalk.net","subject":"[PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-14T10:24:24Z","receivedAt":"2017-06-14T10:24:59Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nI've revised the second two tests as Johannes suggested to drop the\nsed script. The first one is unchanged.\n\nPhillip Wood (3):\n rebase -i: Add test for reflog message\n rebase: Add regression tests for console output\n rebase: Add more regression tests for console output\n\n t/t3404-rebase-interactive.sh | 7 +++\n t/t3420-rebase-autostash.sh | 138 ++++++++++++++++++++++++++++++++++++++++--\n 2 files changed, 141 insertions(+), 4 deletions(-)\n\n-- \n2.13.0\n\n"},{"id":"322227","messageId":"20170614102427.5220-2-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170614102427.5220-1-phillip.wood@talktalk.net","subject":"[PATCH v2 1/3] rebase -i: Add test for reflog message","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-14T10:24:25Z","receivedAt":"2017-06-14T10:25:02Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck that the reflog message written to the branch reflog when the\nrebase is completed is correct\n\nSigned-off-by: Phillip Wood \n---\n t/t3404-rebase-interactive.sh | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 5bd0275930b715c25507fc9744c8946e7f73900b..37821d245433f757fa13f0a3e27da0312bebb7db 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -169,6 +169,13 @@ test_expect_success 'reflog for the branch shows state before rebase' '\n \ttest $(git rev-parse branch1@{1}) = $(git rev-parse original-branch1)\n '\n \n+test_expect_success 'reflog for the branch shows correct finish message' '\n+\tprintf \"rebase -i (finish): refs/heads/branch1 onto %s\\n\" \\\n+\t\t\"$(git rev-parse branch2)\" >expected &&\n+\tgit log -g --pretty=%gs -1 refs/heads/branch1 >actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_expect_success 'exchange two commits' '\n \tset_fake_editor &&\n \tFAKE_LINES=\"2 1\" git rebase -i HEAD~2 &&\n-- \n2.13.0\n\n"},{"id":"322228","messageId":"20170614102427.5220-3-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170614102427.5220-1-phillip.wood@talktalk.net","subject":"[PATCH v2 2/3] rebase: Add regression tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-14T10:24:26Z","receivedAt":"2017-06-14T10:25:07Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck the console output when using --autostash and the stash applies\ncleanly is what we expect. The test is quite strict but should catch\nany changes to the console output from the various rebase flavors.\n\nThanks-to: Johannes Schindelin \nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 66 +++++++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 64 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex ab8a63e8d6dc643b28eb0c74ba3f032b7532226f..2cbc2e89cd026c370a86da35e181d77f27081c7a 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -33,6 +33,62 @@ test_expect_success setup '\n \tgit commit -m \"related commit\"\n '\n \n+create_expected_success_am() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tApplying: second commit\n+\tApplying: third commit\n+\tApplied autostash.\n+\tEOF\n+}\n+\n+create_expected_success_interactive() {\n+\tcr=$'\\r' &&\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tRebasing (1/2)${cr}Rebasing (2/2)${cr}Successfully rebased and updated refs/heads/rebased-feature-branch.\n+\tApplied autostash.\n+\tEOF\n+}\n+\n+create_expected_success_merge() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tMerging unrelated-onto-branch with HEAD~1\n+\tMerging:\n+\t$(git rev-parse --short unrelated-onto-branch) unrelated commit\n+\t$(git rev-parse --short feature-branch^) second commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~2) initial commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:14:13 2005 -0700\n+\t 2 files changed, 2 insertions(+)\n+\t create mode 100644 file1\n+\t create mode 100644 file2\n+\tCommitted: 0001 second commit\n+\tMerging unrelated-onto-branch with HEAD~0\n+\tMerging:\n+\t$(git rev-parse --short rebased-feature-branch~1) second commit\n+\t$(git rev-parse --short feature-branch) third commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~1) second commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:15:13 2005 -0700\n+\t 1 file changed, 1 insertion(+)\n+\t create mode 100644 file3\n+\tCommitted: 0002 third commit\n+\tAll done.\n+\tApplied autostash.\n+\tEOF\n+}\n+\n testrebase() {\n \ttype=$1\n \tdotest=$2\n@@ -51,14 +107,20 @@ testrebase() {\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n \t\tgit checkout -b rebased-feature-branch feature-branch &&\n-\t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >>file3 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >actual 2>&1 &&\n \t\tgrep unrelated file4 &&\n \t\tgrep dirty file3 &&\n \t\tgit checkout feature-branch\n \t'\n \n+\ttest_expect_success \"rebase$type --autostash: check output\" '\n+\t\ttest_when_finished git branch -D rebased-feature-branch &&\n+\t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n+\t\tcreate_expected_success_$suffix &&\n+\t\ttest_cmp expected actual\n+\t'\n+\n \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n-- \n2.13.0\n\n"},{"id":"322229","messageId":"20170614102427.5220-4-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170614102427.5220-1-phillip.wood@talktalk.net","subject":"[PATCH v2 3/3] rebase: Add more regression tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-14T10:24:27Z","receivedAt":"2017-06-14T10:25:11Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck the console output when using --autostash and the stash does not\napply is what we expect. The test is quite strict but should catch any\nchanges to the console output from the various rebase flavors.\n\nThanks-to: Johannes Schindelin \nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 72 +++++++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 70 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 2cbc2e89cd026c370a86da35e181d77f27081c7a..325ec75353b200bb88ab223e4a3b87d885cf2cf2 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -89,6 +89,68 @@ create_expected_success_merge() {\n \tEOF\n }\n \n+create_expected_failure_am() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tApplying: second commit\n+\tApplying: third commit\n+\tApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tEOF\n+}\n+\n+create_expected_failure_interactive() {\n+\tcr=$'\\r' &&\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tRebasing (1/2)${cr}Rebasing (2/2)${cr}Successfully rebased and updated refs/heads/rebased-feature-branch.\n+\tApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tEOF\n+}\n+\n+create_expected_failure_merge() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tMerging unrelated-onto-branch with HEAD~1\n+\tMerging:\n+\t$(git rev-parse --short unrelated-onto-branch) unrelated commit\n+\t$(git rev-parse --short feature-branch^) second commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~2) initial commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:14:13 2005 -0700\n+\t 2 files changed, 2 insertions(+)\n+\t create mode 100644 file1\n+\t create mode 100644 file2\n+\tCommitted: 0001 second commit\n+\tMerging unrelated-onto-branch with HEAD~0\n+\tMerging:\n+\t$(git rev-parse --short rebased-feature-branch~1) second commit\n+\t$(git rev-parse --short feature-branch) third commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~1) second commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:15:13 2005 -0700\n+\t 1 file changed, 1 insertion(+)\n+\t create mode 100644 file3\n+\tCommitted: 0002 third commit\n+\tAll done.\n+\tApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tEOF\n+}\n+\n testrebase() {\n \ttype=$1\n \tdotest=$2\n@@ -199,10 +261,9 @@ testrebase() {\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n \t\tgit checkout -b rebased-feature-branch feature-branch &&\n-\t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >file4 &&\n \t\tgit add file4 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >actual 2>&1 &&\n \t\ttest_path_is_missing $dotest &&\n \t\tgit reset --hard &&\n \t\tgrep unrelated file4 &&\n@@ -211,6 +272,13 @@ testrebase() {\n \t\tgit stash pop &&\n \t\tgrep dirty file4\n \t'\n+\n+\ttest_expect_success \"rebase$type: check output with conflicting stash\" '\n+\t\ttest_when_finished git branch -D rebased-feature-branch &&\n+\t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n+\t\tcreate_expected_failure_$suffix &&\n+\t\ttest_cmp expected actual\n+\t'\n }\n \n test_expect_success \"rebase: fast-forward rebase\" '\n-- \n2.13.0\n\n"},{"id":"322246","messageId":"alpine.DEB.2.21.1.1706141446370.171564@virtualbox","threadId":"46075","inReplyTo":"5309bbe7-edd8-0c34-82ff-c3162d7d9e66@talktalk.net","subject":"Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-14T12:51:57Z","receivedAt":"2017-06-14T12:52:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 7 Jun 2017, Phillip Wood wrote:\n\n> On 01/06/17 13:56, Johannes Schindelin wrote:\n> > \n> > On Wed, 31 May 2017, Phillip Wood wrote:\n> > \n> >> From: Phillip Wood \n> >>\n> >> Check the console output when using --autostash and the stash applies\n> >> cleanly is what we expect. To avoid this test depending on commit and\n> >> stash hashes it uses sed to replace them with XXX. The sed script also\n> >> replaces carriage returns in the output with '\\r' to avoid embedded\n> >> '^M's in the expected output files. Unfortunately this means we still\n> >> end up with an embedded '^M' in the sed script which may not be\n> >> preserved when sending this. The last line of the sed script should be\n> >> +s/^M/\\\\r/g\n> > \n> > Like Junio pointed out, this sed script would not be portable. To\n> > elaborate: there are two major variants of sed out there, GNU sed and BSD\n> > sed. Typically GNU sed allows a little more powerful instructions, e.g. \\t\n> > and \\r.\n> \n> I'm confused by this as my script does not use the escape sequence \"\\r\"\n> out of portability concerns. It has a literal carriage return as you get\n> from typing Ctrl-Q Ctrl-M in emacs or Ctrl-V Ctrl-M in bash which I\n> think should be portable and replaces the carriage returns in git's\n> output with the literal string '\\r'. I did this so that the expected\n> files don't have control characters in them that mess up the display\n> when you cat them or read them in an email client\n\nJunio elaborated elsewhere what my main concern is: while a literal\nbackslash followed by a lower-case r may be unportable, a plain CR byte is\nalmost certainly unportable.\n\n> > Taking an additional step back, I wonder whether we have to hard-code\n> > the commit IDs (or XXX) to begin with. Why not generate the `expect`\n> > files with the information at hand? We can simply ask `git rev-parse\n> > --short`.\n> > \n> > For the stash's commit ID, there is no record in the ref space, of\n> > course (because it was created with `git stash create`). But I think\n> > in this case, it is legitimate to simply grep the output.\n> \n> That's a good approach to handling the stash hash if we want to generate\n> the expected files from the test script\n\nI would strongly favor that, especially since it would make the transition\naway from SHA-1 easier rather than more difficult.\n\n> > That way, the test would be precise and resilient.\n> > \n> > So for example instead of adding the t/t3420/expected-success-am verbatim,\n> > you could generate the output via\n> > \n> > \tcat >expect <<-EOF\n> > \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\\\$\" output)\n> > \tHEAD is now at $(git rev-parse --short HEAD~2) third commit\n> > \tFirst, rewinding head to replay your work on top of it...\n> > \tApplying: second commit\n> > \tApplying: third commit\n> > \tApplied autostash.\n> > \tEOF\n> \n> This approach works well for the cases where there aren't control\n> characters embedded in git's output, but for the interactive tests there\n> are so we'd end up with control characters in the test script which I\n> wanted to avoid or doing $(printf '\\r'). I steered clear of generating\n> the expected file in the test as i) it was more work (both for me\n> (rebase --merge has a few commit hashes in it's output) and when the\n> script is running) and ii) it's a bit messy to implement given the way\n> the tests are structured in a helper function that's called with a\n> parameter indicating the type of rebase to test.\n> \n> I can go ahead with generating the expected files from the script if you\n> really want but I wonder if changing the test to generate the sed script\n> with printf as below might be a simpler way to mitigate the carriage\n> return problem, though it would be less strict than generating the real\n> hashes with rev-parse.\n> \n> --- a/t/t3420-rebase-autostash.sh\n> +++ b/t/t3420-rebase-autostash.sh\n> @@ -189,6 +189,16 @@ test_expect_success \"rebase: noop rebase\" '\n> \tgit checkout feature-branch\n> '\n> \n> +test_expect_sucess 'rebase: create sed script to sanitize output' '\n> +\tprintf \"\\\n> +s/^\\(Created autostash: \\)[0-9a-f]\\{6,\\}$/\\1XXX/\n> +s/^\\(HEAD is now at \\)[0-9a-f]\\{6,\\}\\( .* commit\\)$/\\1XXX\\2/\n> +s/^[0-9a-f]\\{6,\\}\\( .* commit\\)$/XXX\\1/\n> +s/\\(detached HEAD \\)[0-9a-f]\\{6,\\}/\\1XXX/\n> +s/\\(could not apply \\)[0-9a-f]\\{6,\\}/\\1XXX/g\n> +s/\\\\r/\\\\r/g\" >$TEST_DIRECTORY/t4320/remove-ids.sed\n> +'\n> +\n> \n> Let me know what you think,\n\nI'd rather generate the expected output. If there are control characters\nto be embedded anywhere, we have good prior art to do that: see the\nq_to_nul(), q_to_cr() and q_to_tab() functions in test-lib-functions.\n\nIf you still think that it is too daunting, please point me to a branch\n(you're on GitHub, right?) and I can try my hand at a PR.\n\nCiao,\nDscho\n"},{"id":"322287","messageId":"alpine.DEB.2.21.1.1706142235260.171564@virtualbox","threadId":"46075","inReplyTo":"20170614102427.5220-1-phillip.wood@talktalk.net","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-14T20:35:45Z","receivedAt":"2017-06-14T20:36:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 14 Jun 2017, Phillip Wood wrote:\n\n> From: Phillip Wood \n> \n> I've revised the second two tests as Johannes suggested to drop the\n> sed script. The first one is unchanged.\n\nThis iteration looks pretty good to me!\n\nCiao,\nJohannes\n"},{"id":"322309","messageId":"alpine.DEB.2.21.1.1706151235480.4200@virtualbox","threadId":"46075","inReplyTo":"CACBZZX7JRA2niwt9wsGAxnzS+gWS8hTUgzWm8NaY1gs87o8xVQ@mail.gmail.com","subject":"Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-15T10:38:44Z","receivedAt":"2017-06-15T10:38:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Fri, 2 Jun 2017, Ævar Arnfjörð Bjarmason wrote:\n\n> On Fri, Jun 2, 2017 at 7:54 PM, Jonathan Nieder wrote:\n> >\n> > Johannes Schindelin wrote:\n> >> On Thu, 1 Jun 2017, Stefan Beller wrote:\n> >\n> >>> We had a discussion off list how much of the test suite is in bad\n> >>> shape, and \"$ git grep ^index\" points out a lot of places as well.\n> >>\n> >> Maybe we should call out a specific month (or even a longer period)\n> >> during which we try to push toward that new hash function, and focus\n> >> more on those tasks (and on critical bug fixes, if any) than anything\n> >> else.\n> >\n> > Thanks for offering. ;-)\n> >\n> > Here's a rough list of some useful tasks, in no particular order:\n> >\n> > 1. bc/object-id: This patch series continues, eliminating assumptions\n> > about the size of object ids by encapsulating them in a struct.\n> > One straightforward way to find code that still needs to be\n> > converted is to grep for \"sha\" --- often the conversion patches\n> > change function and variable names to refer to oid_ where they used\n> > to use sha1_, making the stragglers easier to spot.\n> >\n> > 2. Hard-coded object ids in tests: As Stefan hinted, many tests beyond\n> > t00* make assumptions about the exact values of object ids. That's\n> > bad for maintainability for other reasons beyond the hash function\n> > transition, too.\n> >\n> > It should be possible to suss them out by patching git's sha1\n> > routine to use the ones-complement of sha1 (~sha1) instead and\n> > seeing which tests fail.\n> \n> I just hacked this up locally.\n\nWould you mind turning that into a patch? I figure this could be a\ncompile-time switch and applied to Git's `master` so that it is easier to\nfind those assumptions, as well as verify fixes on multiple platforms.\n\n> > 4. When choosing a hash function, people may argue about performance.\n> > It would be useful for run some benchmarks for git (running\n> > the test suite, t/perf tests, etc) using a variety of hash\n> > functions as input to such a discussion.\n> \n> To the extent that such benchmarks matter, it seems prudent to heavily\n> weigh them in favor of whatever seems to be likely to be the more\n> common hash function going forward, since those are likely to get\n> faster through future hardware acceleration.\n\nExactly.\n\nAs I just mentioned elsewhere, the cryptographers I talked to expect\nSHA-256 and SHA3-256 to see the most focus of all hash functions, by far.\n\n> E.g. Intel announced Goldmont last year which according to one SHA-1\n> implementation improved from 9.5 cycles per byte to 2.7 cpb[1]. They\n> only have acceleration for SHA-1 and SHA-256[2]\n> \n> 1. https://github.com/weidai11/cryptopp/issues/139#issuecomment-264283385\n> \n> 2. https://en.wikipedia.org/wiki/Goldmont\n\nThanks for digging that up! Very valuable information.\n\nCiao,\nDscho"},{"id":"322411","messageId":"xmqqshj0yhq1.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170614102427.5220-1-phillip.wood@talktalk.net","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-15T23:05:42Z","receivedAt":"2017-06-15T23:05:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> From: Phillip Wood \n>\n> I've revised the second two tests as Johannes suggested to drop the\n> sed script. The first one is unchanged.\n>\n> Phillip Wood (3):\n> rebase -i: Add test for reflog message\n> rebase: Add regression tests for console output\n> rebase: Add more regression tests for console output\n>\n> t/t3404-rebase-interactive.sh | 7 +++\n> t/t3420-rebase-autostash.sh | 138 ++++++++++++++++++++++++++++++++++++++++--\n> 2 files changed, 141 insertions(+), 4 deletions(-)\n\nThanks (and thanks for Dscho for reading it over).\n\nUnfortunately this breaks unless your shell is bash (I didn't have\ntime to look further into it), i.e. \"make SHELL_PATH=/bin/dash test\"\n\n"},{"id":"322421","messageId":"xmqqk24cygvm.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"xmqqshj0yhq1.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-15T23:23:57Z","receivedAt":"2017-06-15T23:24:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Phillip Wood writes:\n>\n>> From: Phillip Wood \n>>\n>> I've revised the second two tests as Johannes suggested to drop the\n>> sed script. The first one is unchanged.\n>>\n>> Phillip Wood (3):\n>> rebase -i: Add test for reflog message\n>> rebase: Add regression tests for console output\n>> rebase: Add more regression tests for console output\n>>\n>> t/t3404-rebase-interactive.sh | 7 +++\n>> t/t3420-rebase-autostash.sh | 138 ++++++++++++++++++++++++++++++++++++++++--\n>> 2 files changed, 141 insertions(+), 4 deletions(-)\n>\n> Thanks (and thanks for Dscho for reading it over).\n>\n> Unfortunately this breaks unless your shell is bash (I didn't have\n> time to look further into it), i.e. \"make SHELL_PATH=/bin/dash test\"\n\nThis is the bash-ism that broke it, I think.\n\n create_expected_success_interactive() {\n cr=$'\\r' &&\n cat >expected <<-EOF\n\n"},{"id":"322422","messageId":"xmqqfuf0ygmu.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"xmqqk24cygvm.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-15T23:29:13Z","receivedAt":"2017-06-15T23:29:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n>> Phillip Wood writes:\n>>\n>>> From: Phillip Wood \n>>>\n>>> I've revised the second two tests as Johannes suggested to drop the\n>>> sed script. The first one is unchanged.\n>>>\n>>> Phillip Wood (3):\n>>> rebase -i: Add test for reflog message\n>>> rebase: Add regression tests for console output\n>>> rebase: Add more regression tests for console output\n>>>\n>>> t/t3404-rebase-interactive.sh | 7 +++\n>>> t/t3420-rebase-autostash.sh | 138 ++++++++++++++++++++++++++++++++++++++++--\n>>> 2 files changed, 141 insertions(+), 4 deletions(-)\n>>\n>> Thanks (and thanks for Dscho for reading it over).\n>>\n>> Unfortunately this breaks unless your shell is bash (I didn't have\n>> time to look further into it), i.e. \"make SHELL_PATH=/bin/dash test\"\n>\n> This is the bash-ism that broke it, I think.\n>\n> create_expected_success_interactive() {\n> cr=$'\\r' &&\n> cat >expected <<-EOF\n\nFYI, I've queued the following as a fix-up and pushed the result\nout.\n\n t/t3420-rebase-autostash.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 325ec75353..801bce25da 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -45,7 +45,7 @@ create_expected_success_am() {\n }\n \n create_expected_success_interactive() {\n-\tcr=$'\\r' &&\n+\tcr=$(echo . | tr '.' '\\015') &&\n \tcat >expected <<-EOF\n \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n@@ -103,7 +103,7 @@ create_expected_failure_am() {\n }\n \n create_expected_failure_interactive() {\n-\tcr=$'\\r' &&\n+\tcr=$(echo . | tr '.' '\\015') &&\n \tcat >expected <<-EOF\n \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n-- \n2.13.1-591-gf514f8f1c0\n\n"},{"id":"322459","messageId":"alpine.DEB.2.21.1.1706161527140.4200@virtualbox","threadId":"46075","inReplyTo":"xmqqfuf0ygmu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-06-16T13:49:49Z","receivedAt":"2017-06-16T13:50:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 15 Jun 2017, Junio C Hamano wrote:\n\n> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n> index 325ec75353..801bce25da 100755\n> --- a/t/t3420-rebase-autostash.sh\n> +++ b/t/t3420-rebase-autostash.sh\n> @@ -45,7 +45,7 @@ create_expected_success_am() {\n> }\n> \n> create_expected_success_interactive() {\n> -\tcr=$'\\r' &&\n> +\tcr=$(echo . | tr '.' '\\015') &&\n> \tcat >expected <<-EOF\n> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n> \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n\nThis is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\nwould emit) is interpreted correctly as a line break on Windows, meaning\nthat cr is now *empty*. Not what we want.\n\nWhat I did is to replace the `cat` by `q_to_cr` (we have that lovely\nfunction, might just as well use it), replace `${cr}` by `Q` and skip the\ncr variable altogether.\n\nAdditionally, there is another huge problem: the \"Applied autostash.\" is\nprinted to stdout, not stderr, in line with how things were done in the\nshell version of rebase -i.\n\nWhile this was just a minor bug previously, now we exercise that bug, by\nredirecting stderr to stdout and redirecting stdout to the file `actual`.\nNothing says that stderr should be printed to that file before stdout, but\nthat is exactly what the test case tries to verify.\n\nThere is only one slight problem: in my Git for Windows SDK, stdout is\nprinted first.\n\nThe quick fix would be to redirect stderr and stdout independently.\n\nHowever, I think it is time for that bug to be fixed: autostash messages\nshould really go to stderr, just like the rest of them rebase messages.\n\nI attached the patch, together with the two fixups to Phillip's patches,\nand a fixup for the autostash-messages-to-stderr patch that I think should\nbe squashed in but I really ran out of time testing this.\n\nPhillip, would you mind picking those changes up as you deem appropriate?\n\nCiao,\nDscho\n\nFrom c5a8319f0378d93be5aea05b833bb5e23c9f0b3d Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Fri, 16 Jun 2017 15:34:50 +0200\nSubject: [PATCH 1/4] sequencer: print autostash messages to stderr\n\nThe rebase messages are printed to stderr traditionally. It was a bug\nintroduced in 587947750bd (rebase: implement --[no-]autostash and\nrebase.autostash, 2013-05-12) and that bug has been faithfully copied\nwhen reimplementing parts of the interactive rebase in the sequencer.\n\nIt is time to fix that: let's print the autostash messages to stderr\ninstead of stdout.\n\nSigned-off-by: Johannes Schindelin \n---\n sequencer.c | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/sequencer.c b/sequencer.c\nindex a59408a23a2..8713cc8d1d5 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -1923,7 +1923,7 @@ static int apply_autostash(struct replay_opts *opts)\n \targv_array_push(&child.args, \"apply\");\n \targv_array_push(&child.args, stash_sha1.buf);\n \tif (!run_command(&child))\n-\t\tprintf(_(\"Applied autostash.\\n\"));\n+\t\tfprintf(stderr, _(\"Applied autostash.\\n\"));\n \telse {\n \t\tstruct child_process store = CHILD_PROCESS_INIT;\n \n@@ -1937,10 +1937,11 @@ static int apply_autostash(struct replay_opts *opts)\n \t\tif (run_command(&store))\n \t\t\tret = error(_(\"cannot store %s\"), stash_sha1.buf);\n \t\telse\n-\t\t\tprintf(_(\"Applying autostash resulted in conflicts.\\n\"\n-\t\t\t\t\"Your changes are safe in the stash.\\n\"\n-\t\t\t\t\"You can run \\\"git stash pop\\\" or\"\n-\t\t\t\t\" \\\"git stash drop\\\" at any time.\\n\"));\n+\t\t\tfprintf(stderr,\n+\t\t\t\t_(\"Applying autostash resulted in conflicts.\\n\"\n+\t\t\t\t \"Your changes are safe in the stash.\\n\"\n+\t\t\t\t \"You can run \\\"git stash pop\\\" or\"\n+\t\t\t\t \" \\\"git stash drop\\\" at any time.\\n\"));\n \t}\n \n \tstrbuf_release(&stash_sha1);\n-- \n2.12.2.windows.1\n\n\n\nFrom 3425f7c9bfb62c3d2d4adaff41a664dd4ae2efa9 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Fri, 16 Jun 2017 15:39:20 +0200\nSubject: [PATCH 2/4] fixup! rebase: add regression tests for console output\n\nSigned-off-by: Johannes Schindelin \n---\n t/t3420-rebase-autostash.sh | 7 +++----\n 1 file changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 801bce25da4..64904bef069 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -45,12 +45,11 @@ create_expected_success_am() {\n }\n \n create_expected_success_interactive() {\n-\tcr=$(echo . | tr '.' '\\015') &&\n-\tcat >expected <<-EOF\n+\tq_to_cr >expected <<-EOF\n \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n-\tRebasing (1/2)${cr}Rebasing (2/2)${cr}Successfully rebased and updated refs/heads/rebased-feature-branch.\n-\tApplied autostash.\n+\tRebasing (1/2)QRebasing (2/2)QApplied autostash.\n+\tSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n \tEOF\n }\n \n-- \n2.12.2.windows.1\n\n\n\nFrom e16ad989c85c55bdfcf45fe561911a699e962b44 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Fri, 16 Jun 2017 15:39:35 +0200\nSubject: [PATCH 3/4] fixup! rebase: add more regression tests for console\n output\n\nSigned-off-by: Johannes Schindelin \n---\n t/t3420-rebase-autostash.sh | 7 +++----\n 1 file changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 64904bef069..2c01ae6ad2a 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -102,14 +102,13 @@ create_expected_failure_am() {\n }\n \n create_expected_failure_interactive() {\n-\tcr=$(echo . | tr '.' '\\015') &&\n-\tcat >expected <<-EOF\n+\tq_to_cr >expected <<-EOF\n \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n-\tRebasing (1/2)${cr}Rebasing (2/2)${cr}Successfully rebased and updated refs/heads/rebased-feature-branch.\n-\tApplying autostash resulted in conflicts.\n+\tRebasing (1/2)QRebasing (2/2)QApplying autostash resulted in conflicts.\n \tYour changes are safe in the stash.\n \tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n \tEOF\n }\n \n-- \n2.12.2.windows.1\n\n\n\nFrom 128c4a66ab3413b2135264f17024e1f5e9250f03 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Fri, 16 Jun 2017 15:40:46 +0200\nSubject: [PATCH 4/4] fixup! sequencer: print autostash messages to stderr\n\nThis is the companion to the proposed patch, but I had no time to verify\nthat the test suite still passes (it may actually test for the buggy\nbehavior...)\n\nSigned-off-by: Johannes Schindelin \n---\n git-rebase.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex db1deed8464..2cf73b88e8e 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -166,14 +166,14 @@ apply_autostash () {\n \t\tstash_sha1=$(cat \"$state_dir/autostash\")\n \t\tif git stash apply $stash_sha1 2>&1 >/dev/null\n \t\tthen\n-\t\t\techo \"$(gettext 'Applied autostash.')\"\n+\t\t\techo \"$(gettext 'Applied autostash.')\" >&2\n \t\telse\n \t\t\tgit stash store -m \"autostash\" -q $stash_sha1 ||\n \t\t\tdie \"$(eval_gettext \"Cannot store \\$stash_sha1\")\"\n \t\t\tgettext 'Applying autostash resulted in conflicts.\n Your changes are safe in the stash.\n You can run \"git stash pop\" or \"git stash drop\" at any time.\n-'\n+' >&2\n \t\tfi\n \tfi\n }\n-- \n2.12.2.windows.1\n\n"},{"id":"322473","messageId":"3c975634-8651-af74-66bf-ee793bc073fc@kdbg.org","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706161527140.4200@virtualbox","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-06-16T18:43:26Z","receivedAt":"2017-06-16T18:43:35Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:\n> On Thu, 15 Jun 2017, Junio C Hamano wrote:\n>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n>> index 325ec75353..801bce25da 100755\n>> --- a/t/t3420-rebase-autostash.sh\n>> +++ b/t/t3420-rebase-autostash.sh\n>> @@ -45,7 +45,7 @@ create_expected_success_am() {\n>> }\n>> \n>> create_expected_success_interactive() {\n>> -\tcr=$'\\r' &&\n>> +\tcr=$(echo . | tr '.' '\\015') &&\n>> \tcat >expected <<-EOF\n>> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n>> \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n> \n> This is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\n> would emit) is interpreted correctly as a line break on Windows, meaning\n> that cr is now *empty*. Not what we want.\n> \n> What I did is to replace the `cat` by `q_to_cr` (we have that lovely\n> function, might just as well use it), replace `${cr}` by `Q` and skip the\n> cr variable altogether.\n\nYou beat me to it. I came up with the identical q_to_cr changes, but \nhaven't dug the remaining failure regarding the swapped output lines. \nYou seem to have nailed it. Will test your proposed changes tomorrow.\n\n-- Hannes\n"},{"id":"322486","messageId":"xmqqvanvwsn5.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"3c975634-8651-af74-66bf-ee793bc073fc@kdbg.org","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-16T21:05:02Z","receivedAt":"2017-06-16T21:05:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:\n>> On Thu, 15 Jun 2017, Junio C Hamano wrote:\n>>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n>>> index 325ec75353..801bce25da 100755\n>>> --- a/t/t3420-rebase-autostash.sh\n>>> +++ b/t/t3420-rebase-autostash.sh\n>>> @@ -45,7 +45,7 @@ create_expected_success_am() {\n>>> }\n>>> create_expected_success_interactive() {\n>>> -\tcr=$'\\r' &&\n>>> +\tcr=$(echo . | tr '.' '\\015') &&\n>>> \tcat >expected <<-EOF\n>>> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n>>> \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n>>\n>> This is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\n>> would emit) is interpreted correctly as a line break on Windows, meaning\n>> that cr is now *empty*. Not what we want.\n>>\n>> What I did is to replace the `cat` by `q_to_cr` (we have that lovely\n>> function, might just as well use it), replace `${cr}` by `Q` and skip the\n>> cr variable altogether.\n>\n> You beat me to it. I came up with the identical q_to_cr changes, but\n> haven't dug the remaining failure regarding the swapped output\n> lines. You seem to have nailed it. Will test your proposed changes\n> tomorrow.\n\nOuch. Thanks, both of you.\n"},{"id":"322556","messageId":"969f3069-d386-a2ec-736d-e67d6f17a590@talktalk.net","threadId":"46075","inReplyTo":"alpine.DEB.2.21.1.1706161527140.4200@virtualbox","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T09:49:57Z","receivedAt":"2017-06-19T09:50:06Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 16/06/17 14:49, Johannes Schindelin wrote:\n> Hi Junio,\n> \n> On Thu, 15 Jun 2017, Junio C Hamano wrote:\n> \n>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n>> index 325ec75353..801bce25da 100755\n>> --- a/t/t3420-rebase-autostash.sh\n>> +++ b/t/t3420-rebase-autostash.sh\n>> @@ -45,7 +45,7 @@ create_expected_success_am() {\n>> }\n>> \n>> create_expected_success_interactive() {\n>> -\tcr=$'\\r' &&\n>> +\tcr=$(echo . | tr '.' '\\015') &&\n>> \tcat >expected <<-EOF\n>> \t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n>> \tHEAD is now at $(git rev-parse --short feature-branch) third commit\n> \n> This is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\n> would emit) is interpreted correctly as a line break on Windows, meaning\n> that cr is now *empty*. Not what we want.\n> \n> What I did is to replace the `cat` by `q_to_cr` (we have that lovely\n> function, might just as well use it), replace `${cr}` by `Q` and skip the\n> cr variable altogether.\n> \n> Additionally, there is another huge problem: the \"Applied autostash.\" is\n> printed to stdout, not stderr, in line with how things were done in the\n> shell version of rebase -i.\n> \n> While this was just a minor bug previously, now we exercise that bug, by\n> redirecting stderr to stdout and redirecting stdout to the file `actual`.\n> Nothing says that stderr should be printed to that file before stdout, but\n> that is exactly what the test case tries to verify.\n> \n> There is only one slight problem: in my Git for Windows SDK, stdout is\n> printed first.\n> \n> The quick fix would be to redirect stderr and stdout independently.\n> \n> However, I think it is time for that bug to be fixed: autostash messages\n> should really go to stderr, just like the rest of them rebase messages.\n> \n> I attached the patch, together with the two fixups to Phillip's patches,\n> and a fixup for the autostash-messages-to-stderr patch that I think should\n> be squashed in but I really ran out of time testing this.\n> \n> Phillip, would you mind picking those changes up as you deem appropriate?\n\nWill do, thanks for the patches\n\n"},{"id":"322558","messageId":"0013aa76-d743-e002-72b6-68e1a567fdbc@talktalk.net","threadId":"46075","inReplyTo":"xmqqfuf0ygmu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T09:52:33Z","receivedAt":"2017-06-19T09:52:43Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 16/06/17 00:29, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> Junio C Hamano writes:\n>>\n>>> Phillip Wood writes:\n>>>\n>>>> From: Phillip Wood \n>>>>\n>>>> I've revised the second two tests as Johannes suggested to drop the\n>>>> sed script. The first one is unchanged.\n>>>>\n>>>> Phillip Wood (3):\n>>>> rebase -i: Add test for reflog message\n>>>> rebase: Add regression tests for console output\n>>>> rebase: Add more regression tests for console output\n>>>>\n>>>> t/t3404-rebase-interactive.sh | 7 +++\n>>>> t/t3420-rebase-autostash.sh | 138 ++++++++++++++++++++++++++++++++++++++++--\n>>>> 2 files changed, 141 insertions(+), 4 deletions(-)\n>>>\n>>> Thanks (and thanks for Dscho for reading it over).\n>>>\n>>> Unfortunately this breaks unless your shell is bash (I didn't have\n>>> time to look further into it), i.e. \"make SHELL_PATH=/bin/dash test\"\n>>\n>> This is the bash-ism that broke it, I think.\n>>\n>> create_expected_success_interactive() {\n>> cr=$'\\r' &&\n>> cat >expected <<-EOF\n\nSorry about that, for some reason I thought $' was in the posix shell\nstandard but it's not. I'll redo the patches with the changes Johannes\nsuggested.\n"},{"id":"322566","messageId":"xmqqwp88t200.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"969f3069-d386-a2ec-736d-e67d6f17a590@talktalk.net","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-19T15:45:35Z","receivedAt":"2017-06-19T15:45:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n>> Phillip, would you mind picking those changes up as you deem appropriate?\n>\n> Will do, thanks for the patches\n\nThanks, both.\n"},{"id":"322585","messageId":"20170619175605.27864-1-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170531104213.16944-1-phillip.wood@talktalk.net","subject":"[PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T17:56:01Z","receivedAt":"2017-06-19T17:56:20Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nI've updated the second two tests to be portable using q_to_cr() as\nJohannes suggested and added his patch to fix the autostash messages\ngoing to stdout rather than stderr. The reflog message test is\nunchanged. Thanks to Johannes for his help and to Junio for picking up\nthe bashism in the last iteration.\n\nJohannes Schindelin (1):\n sequencer: print autostash messages to stderr\n\nPhillip Wood (3):\n rebase -i: Add test for reflog message\n rebase: Add regression tests for console output\n rebase: Add more regression tests for console output\n\n git-rebase.sh | 4 +-\n sequencer.c | 11 ++--\n t/t3404-rebase-interactive.sh | 7 +++\n t/t3420-rebase-autostash.sh | 136 ++++++++++++++++++++++++++++++++++++++++--\n 4 files changed, 147 insertions(+), 11 deletions(-)\n\n-- \n2.13.0\n\n"},{"id":"322587","messageId":"20170619175605.27864-2-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170619175605.27864-1-phillip.wood@talktalk.net","subject":"[PATCH v3 1/4] sequencer: print autostash messages to stderr","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T17:56:02Z","receivedAt":"2017-06-19T17:57:04Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Johannes Schindelin \n\nThe rebase messages are printed to stderr traditionally. However due\nto a bug introduced in 587947750bd (rebase: implement --[no-]autostash\nand rebase.autostash, 2013-05-12) which was faithfully copied when\nreimplementing parts of the interactive rebase in the sequencer the\nautostash messages are printed to stdout instead.\n\nIt is time to fix that: let's print the autostash messages to stderr\ninstead of stdout.\n\nSigned-off-by: Johannes Schindelin \nSigned-off-by: Phillip Wood \n---\n git-rebase.sh | 4 ++--\n sequencer.c | 11 ++++++-----\n 2 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex db1deed8464f0643763ed6e3c5e54221cad8c985..2cf73b88e8e83ca34b9eb319dbc2b0a220139b0f 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -166,14 +166,14 @@ apply_autostash () {\n \t\tstash_sha1=$(cat \"$state_dir/autostash\")\n \t\tif git stash apply $stash_sha1 2>&1 >/dev/null\n \t\tthen\n-\t\t\techo \"$(gettext 'Applied autostash.')\"\n+\t\t\techo \"$(gettext 'Applied autostash.')\" >&2\n \t\telse\n \t\t\tgit stash store -m \"autostash\" -q $stash_sha1 ||\n \t\t\tdie \"$(eval_gettext \"Cannot store \\$stash_sha1\")\"\n \t\t\tgettext 'Applying autostash resulted in conflicts.\n Your changes are safe in the stash.\n You can run \"git stash pop\" or \"git stash drop\" at any time.\n-'\n+' >&2\n \t\tfi\n \tfi\n }\ndiff --git a/sequencer.c b/sequencer.c\nindex a23b948ac148304dbebfe38955ec8b40cab3e1e5..606750b1e0c900a9fb43cea224d27ab36ca29ab9 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -1921,7 +1921,7 @@ static int apply_autostash(struct replay_opts *opts)\n \targv_array_push(&child.args, \"apply\");\n \targv_array_push(&child.args, stash_sha1.buf);\n \tif (!run_command(&child))\n-\t\tprintf(_(\"Applied autostash.\\n\"));\n+\t\tfprintf(stderr, _(\"Applied autostash.\\n\"));\n \telse {\n \t\tstruct child_process store = CHILD_PROCESS_INIT;\n \n@@ -1935,10 +1935,11 @@ static int apply_autostash(struct replay_opts *opts)\n \t\tif (run_command(&store))\n \t\t\tret = error(_(\"cannot store %s\"), stash_sha1.buf);\n \t\telse\n-\t\t\tprintf(_(\"Applying autostash resulted in conflicts.\\n\"\n-\t\t\t\t\"Your changes are safe in the stash.\\n\"\n-\t\t\t\t\"You can run \\\"git stash pop\\\" or\"\n-\t\t\t\t\" \\\"git stash drop\\\" at any time.\\n\"));\n+\t\t\tfprintf(stderr,\n+\t\t\t\t_(\"Applying autostash resulted in conflicts.\\n\"\n+\t\t\t\t \"Your changes are safe in the stash.\\n\"\n+\t\t\t\t \"You can run \\\"git stash pop\\\" or\"\n+\t\t\t\t \" \\\"git stash drop\\\" at any time.\\n\"));\n \t}\n \n \tstrbuf_release(&stash_sha1);\n-- \n2.13.0\n\n"},{"id":"322588","messageId":"20170619175605.27864-3-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170619175605.27864-1-phillip.wood@talktalk.net","subject":"[PATCH v3 2/4] rebase -i: Add test for reflog message","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T17:56:03Z","receivedAt":"2017-06-19T17:57:33Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck that the reflog message written to the branch reflog when the\nrebase is completed is correct\n\nSigned-off-by: Phillip Wood \n---\n t/t3404-rebase-interactive.sh | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 5bd0275930b715c25507fc9744c8946e7f73900b..37821d245433f757fa13f0a3e27da0312bebb7db 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -169,6 +169,13 @@ test_expect_success 'reflog for the branch shows state before rebase' '\n \ttest $(git rev-parse branch1@{1}) = $(git rev-parse original-branch1)\n '\n \n+test_expect_success 'reflog for the branch shows correct finish message' '\n+\tprintf \"rebase -i (finish): refs/heads/branch1 onto %s\\n\" \\\n+\t\t\"$(git rev-parse branch2)\" >expected &&\n+\tgit log -g --pretty=%gs -1 refs/heads/branch1 >actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_expect_success 'exchange two commits' '\n \tset_fake_editor &&\n \tFAKE_LINES=\"2 1\" git rebase -i HEAD~2 &&\n-- \n2.13.0\n\n"},{"id":"322589","messageId":"20170619175605.27864-4-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170619175605.27864-1-phillip.wood@talktalk.net","subject":"[PATCH v3 3/4] rebase: Add regression tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T17:56:04Z","receivedAt":"2017-06-19T17:57:38Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck the console output when using --autostash and the stash applies\ncleanly is what we expect. The test is quite strict but should catch\nany changes to the console output from the various rebase flavors.\n\nThanks-to: Johannes Schindelin \nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 65 +++++++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 63 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex ab8a63e8d6dc643b28eb0c74ba3f032b7532226f..cd1012798cb300f4f1ddeba6fdcad544ca9ea1d9 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -33,6 +33,61 @@ test_expect_success setup '\n \tgit commit -m \"related commit\"\n '\n \n+create_expected_success_am() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tApplying: second commit\n+\tApplying: third commit\n+\tApplied autostash.\n+\tEOF\n+}\n+\n+create_expected_success_interactive() {\n+\tq_to_cr >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tRebasing (1/2)QRebasing (2/2)QApplied autostash.\n+\tSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n+\tEOF\n+}\n+\n+create_expected_success_merge() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tMerging unrelated-onto-branch with HEAD~1\n+\tMerging:\n+\t$(git rev-parse --short unrelated-onto-branch) unrelated commit\n+\t$(git rev-parse --short feature-branch^) second commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~2) initial commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:14:13 2005 -0700\n+\t 2 files changed, 2 insertions(+)\n+\t create mode 100644 file1\n+\t create mode 100644 file2\n+\tCommitted: 0001 second commit\n+\tMerging unrelated-onto-branch with HEAD~0\n+\tMerging:\n+\t$(git rev-parse --short rebased-feature-branch~1) second commit\n+\t$(git rev-parse --short feature-branch) third commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~1) second commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:15:13 2005 -0700\n+\t 1 file changed, 1 insertion(+)\n+\t create mode 100644 file3\n+\tCommitted: 0002 third commit\n+\tAll done.\n+\tApplied autostash.\n+\tEOF\n+}\n+\n testrebase() {\n \ttype=$1\n \tdotest=$2\n@@ -51,14 +106,20 @@ testrebase() {\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n \t\tgit checkout -b rebased-feature-branch feature-branch &&\n-\t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >>file3 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >actual 2>&1 &&\n \t\tgrep unrelated file4 &&\n \t\tgrep dirty file3 &&\n \t\tgit checkout feature-branch\n \t'\n \n+\ttest_expect_success \"rebase$type --autostash: check output\" '\n+\t\ttest_when_finished git branch -D rebased-feature-branch &&\n+\t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n+\t\tcreate_expected_success_$suffix &&\n+\t\ttest_cmp expected actual\n+\t'\n+\n \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n-- \n2.13.0\n\n"},{"id":"322590","messageId":"20170619175605.27864-5-phillip.wood@talktalk.net","threadId":"46075","inReplyTo":"20170619175605.27864-1-phillip.wood@talktalk.net","subject":"[PATCH v3 4/4] rebase: Add more regression tests for console output","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-19T17:56:05Z","receivedAt":"2017-06-19T17:57:42Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nCheck the console output when using --autostash and the stash does not\napply is what we expect. The test is quite strict but should catch any\nchanges to the console output from the various rebase flavors.\n\nThanks-to: Johannes Schindelin \nSigned-off-by: Phillip Wood \n---\n t/t3420-rebase-autostash.sh | 71 +++++++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 69 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex cd1012798cb300f4f1ddeba6fdcad544ca9ea1d9..2c01ae6ad2a104940e388013984e7fa2a0d5aed5 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -88,6 +88,67 @@ create_expected_success_merge() {\n \tEOF\n }\n \n+create_expected_failure_am() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tApplying: second commit\n+\tApplying: third commit\n+\tApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tEOF\n+}\n+\n+create_expected_failure_interactive() {\n+\tq_to_cr >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tRebasing (1/2)QRebasing (2/2)QApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tSuccessfully rebased and updated refs/heads/rebased-feature-branch.\n+\tEOF\n+}\n+\n+create_expected_failure_merge() {\n+\tcat >expected <<-EOF\n+\t$(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n+\tHEAD is now at $(git rev-parse --short feature-branch) third commit\n+\tFirst, rewinding head to replay your work on top of it...\n+\tMerging unrelated-onto-branch with HEAD~1\n+\tMerging:\n+\t$(git rev-parse --short unrelated-onto-branch) unrelated commit\n+\t$(git rev-parse --short feature-branch^) second commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~2) initial commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:14:13 2005 -0700\n+\t 2 files changed, 2 insertions(+)\n+\t create mode 100644 file1\n+\t create mode 100644 file2\n+\tCommitted: 0001 second commit\n+\tMerging unrelated-onto-branch with HEAD~0\n+\tMerging:\n+\t$(git rev-parse --short rebased-feature-branch~1) second commit\n+\t$(git rev-parse --short feature-branch) third commit\n+\tfound 1 common ancestor:\n+\t$(git rev-parse --short feature-branch~1) second commit\n+\t[detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit\n+\t Author: A U Thor \n+\t Date: Thu Apr 7 15:15:13 2005 -0700\n+\t 1 file changed, 1 insertion(+)\n+\t create mode 100644 file3\n+\tCommitted: 0002 third commit\n+\tAll done.\n+\tApplying autostash resulted in conflicts.\n+\tYour changes are safe in the stash.\n+\tYou can run \"git stash pop\" or \"git stash drop\" at any time.\n+\tEOF\n+}\n+\n testrebase() {\n \ttype=$1\n \tdotest=$2\n@@ -198,10 +259,9 @@ testrebase() {\n \t\ttest_config rebase.autostash true &&\n \t\tgit reset --hard &&\n \t\tgit checkout -b rebased-feature-branch feature-branch &&\n-\t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\techo dirty >file4 &&\n \t\tgit add file4 &&\n-\t\tgit rebase$type unrelated-onto-branch &&\n+\t\tgit rebase$type unrelated-onto-branch >actual 2>&1 &&\n \t\ttest_path_is_missing $dotest &&\n \t\tgit reset --hard &&\n \t\tgrep unrelated file4 &&\n@@ -210,6 +270,13 @@ testrebase() {\n \t\tgit stash pop &&\n \t\tgrep dirty file4\n \t'\n+\n+\ttest_expect_success \"rebase$type: check output with conflicting stash\" '\n+\t\ttest_when_finished git branch -D rebased-feature-branch &&\n+\t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n+\t\tcreate_expected_failure_$suffix &&\n+\t\ttest_cmp expected actual\n+\t'\n }\n \n test_expect_success \"rebase: fast-forward rebase\" '\n-- \n2.13.0\n\n"},{"id":"322603","messageId":"8be59224-5bb7-50e6-4381-29c250fb10ec@kdbg.org","threadId":"46075","inReplyTo":"3c975634-8651-af74-66bf-ee793bc073fc@kdbg.org","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-06-19T19:45:39Z","receivedAt":"2017-06-19T19:45:48Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 16.06.2017 um 20:43 schrieb Johannes Sixt:\n> Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:\n>> On Thu, 15 Jun 2017, Junio C Hamano wrote:\n>>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n>>> index 325ec75353..801bce25da 100755\n>>> --- a/t/t3420-rebase-autostash.sh\n>>> +++ b/t/t3420-rebase-autostash.sh\n>>> @@ -45,7 +45,7 @@ create_expected_success_am() {\n>>> }\n>>> create_expected_success_interactive() {\n>>> - cr=$'\\r' &&\n>>> + cr=$(echo . | tr '.' '\\015') &&\n>>> cat >expected <<-EOF\n>>> $(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n>>> HEAD is now at $(git rev-parse --short feature-branch) third \n>>> commit\n>>\n>> This is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\n>> would emit) is interpreted correctly as a line break on Windows, meaning\n>> that cr is now *empty*. Not what we want.\n>>\n>> What I did is to replace the `cat` by `q_to_cr` (we have that lovely\n>> function, might just as well use it), replace `${cr}` by `Q` and skip the\n>> cr variable altogether.\n> \n> You beat me to it. I came up with the identical q_to_cr changes, but \n> haven't dug the remaining failure regarding the swapped output lines. \n> You seem to have nailed it. Will test your proposed changes tomorrow.\n\nAs expected, the patches fix the observed test failures for me, too, if \nthat's still relevant.\n\n-- Hannes\n"},{"id":"322605","messageId":"xmqqr2yfsq3x.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"8be59224-5bb7-50e6-4381-29c250fb10ec@kdbg.org","subject":"Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-19T20:02:26Z","receivedAt":"2017-06-19T20:02:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 16.06.2017 um 20:43 schrieb Johannes Sixt:\n>> Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:\n>>> On Thu, 15 Jun 2017, Junio C Hamano wrote:\n>>>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n>>>> index 325ec75353..801bce25da 100755\n>>>> --- a/t/t3420-rebase-autostash.sh\n>>>> +++ b/t/t3420-rebase-autostash.sh\n>>>> @@ -45,7 +45,7 @@ create_expected_success_am() {\n>>>> }\n>>>> create_expected_success_interactive() {\n>>>> - cr=$'\\r' &&\n>>>> + cr=$(echo . | tr '.' '\\015') &&\n>>>> cat >expected <<-EOF\n>>>> $(grep \"^Created autostash: [0-9a-f][0-9a-f]*\\$\" actual)\n>>>> HEAD is now at $(git rev-parse --short feature-branch) third\n>>>> commit\n>>>\n>>> This is still incorrect, as the \\r\\n (which $(echo . | tr \\.\\ '\\015')\n>>> would emit) is interpreted correctly as a line break on Windows, meaning\n>>> that cr is now *empty*. Not what we want.\n>>>\n>>> What I did is to replace the `cat` by `q_to_cr` (we have that lovely\n>>> function, might just as well use it), replace `${cr}` by `Q` and skip the\n>>> cr variable altogether.\n>>\n>> You beat me to it. I came up with the identical q_to_cr changes, but\n>> haven't dug the remaining failure regarding the swapped output\n>> lines. You seem to have nailed it. Will test your proposed changes\n>> tomorrow.\n>\n> As expected, the patches fix the observed test failures for me, too,\n> if that's still relevant.\n\nThanks for double-checking.\n"},{"id":"323053","messageId":"xmqqa84zgwx9.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"20170619175605.27864-1-phillip.wood@talktalk.net","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-23T04:17:22Z","receivedAt":"2017-06-23T04:17:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> From: Phillip Wood \n>\n> I've updated the second two tests to be portable using q_to_cr() as\n> Johannes suggested and added his patch to fix the autostash messages\n> going to stdout rather than stderr. The reflog message test is\n> unchanged. Thanks to Johannes for his help and to Junio for picking up\n> the bashism in the last iteration.\n>\n> Johannes Schindelin (1):\n> sequencer: print autostash messages to stderr\n>\n> Phillip Wood (3):\n> rebase -i: Add test for reflog message\n> rebase: Add regression tests for console output\n> rebase: Add more regression tests for console output\n>\n> git-rebase.sh | 4 +-\n> sequencer.c | 11 ++--\n> t/t3404-rebase-interactive.sh | 7 +++\n> t/t3420-rebase-autostash.sh | 136 ++++++++++++++++++++++++++++++++++++++++--\n> 4 files changed, 147 insertions(+), 11 deletions(-)\n\nI've merged this to 'next' but I probably shouldn't have before\nmaking sure that Travis tests passes 'pu' while this was still in\nthere. \n\nAt least t3420 seems to fail under GETTEXT_POISON build.\n\n https://travis-ci.org/git/git/jobs/245990993\n\n"},{"id":"323056","messageId":"xmqqwp83fg0h.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"xmqqa84zgwx9.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-23T05:07:58Z","receivedAt":"2017-06-23T05:08:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> git-rebase.sh | 4 +-\n>> sequencer.c | 11 ++--\n>> t/t3404-rebase-interactive.sh | 7 +++\n>> t/t3420-rebase-autostash.sh | 136 ++++++++++++++++++++++++++++++++++++++++--\n>> 4 files changed, 147 insertions(+), 11 deletions(-)\n>\n> I've merged this to 'next' but I probably shouldn't have before\n> making sure that Travis tests passes 'pu' while this was still in\n> there. \n>\n> At least t3420 seems to fail under GETTEXT_POISON build.\n>\n> https://travis-ci.org/git/git/jobs/245990993\n\nThis should be sufficient to make t3420 pass. It seems that t3404\nis also broken under GETTEXT_POISON build, but I won't have time to\nlook at it, at least tonight.\n\n $ make GETTEXT_POISON=YesPlease\n $ cd t && sh ./t3404-*.sh -i -v\n\nto see how it breaks.\n\nThanks.\n\n t/t3420-rebase-autostash.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 6826c38cbd..e243700660 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -178,7 +178,7 @@ testrebase () {\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n \t\tcreate_expected_success_$suffix &&\n-\t\ttest_cmp expected actual\n+\t\ttest_i18ncmp expected actual\n \t'\n \n \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n@@ -275,7 +275,7 @@ testrebase () {\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n \t\tcreate_expected_failure_$suffix &&\n-\t\ttest_cmp expected actual\n+\t\ttest_i18ncmp expected actual\n \t'\n }\n \n"},{"id":"323092","messageId":"bc0c32fa-2df6-a4a3-5966-8efabfa349cd@talktalk.net","threadId":"46075","inReplyTo":"xmqqwp83fg0h.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-23T09:53:37Z","receivedAt":"2017-06-23T09:53:44Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 23/06/17 06:07, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>>> git-rebase.sh | 4 +-\n>>> sequencer.c | 11 ++--\n>>> t/t3404-rebase-interactive.sh | 7 +++\n>>> t/t3420-rebase-autostash.sh | 136 ++++++++++++++++++++++++++++++++++++++++--\n>>> 4 files changed, 147 insertions(+), 11 deletions(-)\n>>\n>> I've merged this to 'next' but I probably shouldn't have before\n>> making sure that Travis tests passes 'pu' while this was still in\n>> there. \n>>\n>> At least t3420 seems to fail under GETTEXT_POISON build.\n>>\n>> https://travis-ci.org/git/git/jobs/245990993\n> \n> This should be sufficient to make t3420 pass. It seems that t3404\n> is also broken under GETTEXT_POISON build, but I won't have time to\n> look at it, at least tonight.\n> \n> $ make GETTEXT_POISON=YesPlease\n> $ cd t && sh ./t3404-*.sh -i -v\n> \n> to see how it breaks.\n\nt3404 passes for me,\n$ make GETTEXT_POISON=YesPlease\n$ cd t &&sh t3404-rebase-interactive.sh -i -v\n...\n# still have 1 known breakage(s)\n# passed all remaining 95 test(s)\n1..96\n\nAlso as far as I can see it passes on travis -\nhttps://travis-ci.org/git/git/jobs/245990993#L910 have I missed\nsomething? Do you want me to submit a fixup patch for t3420 or have you\ngot one already?\n\nThanks\n\nPhillip\n\n> Thanks.\n> \n> t/t3420-rebase-autostash.sh | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n> index 6826c38cbd..e243700660 100755\n> --- a/t/t3420-rebase-autostash.sh\n> +++ b/t/t3420-rebase-autostash.sh\n> @@ -178,7 +178,7 @@ testrebase () {\n> \t\ttest_when_finished git branch -D rebased-feature-branch &&\n> \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n> \t\tcreate_expected_success_$suffix &&\n> -\t\ttest_cmp expected actual\n> +\t\ttest_i18ncmp expected actual\n> \t'\n> \n> \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n> @@ -275,7 +275,7 @@ testrebase () {\n> \t\ttest_when_finished git branch -D rebased-feature-branch &&\n> \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n> \t\tcreate_expected_failure_$suffix &&\n> -\t\ttest_cmp expected actual\n> +\t\ttest_i18ncmp expected actual\n> \t'\n> }\n> \n> \n\n"},{"id":"323114","messageId":"xmqqfueqfxfv.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"bc0c32fa-2df6-a4a3-5966-8efabfa349cd@talktalk.net","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-23T17:03:48Z","receivedAt":"2017-06-23T17:03:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> t3404 passes for me,\n> $ make GETTEXT_POISON=YesPlease\n> $ cd t &&sh t3404-rebase-interactive.sh -i -v\n> ...\n> # still have 1 known breakage(s)\n> # passed all remaining 95 test(s)\n> 1..96\n\nInteresting. The tip of 'pu', which includes this series, does pass\nfor me, too, but the tip of this topic 7d70e6b9 (\"rebase: add more\nregression tests for console output\", 2017-06-19) tested in\nisolation fails, and gives the output at the end of this message.\n\n> Do you want me to submit a fixup patch for t3420 or have you\n> got one already?\n\nFor 3420, I can wrap the two-liner patch I showed here earlier into\na commit on top of the series. \n\n3404 needs a similar fix-up for the series to be able to stand on\nits own. Alternatively, at least we need to understand what in 'pu'\nmakes the result of the merge pass---the symptom indicates that this\ntopic cannot be merged to a released version without that unknown\nother topic in 'pu' merged if we want to keep POISON build passing\nthe tests.\n\nThanks.\n\n-- output from 3404 follows --\n\nInitialized empty Git repository in /home/gitster/git/t/trash directory.t3404-rebase-interactive/.git/\nexpecting success: \n\ttest_commit A file1 &&\n\ttest_commit B file1 &&\n\ttest_commit C file2 &&\n\ttest_commit D file1 &&\n\ttest_commit E file3 &&\n\tgit checkout -b branch1 A &&\n\ttest_commit F file4 &&\n\ttest_commit G file1 &&\n\ttest_commit H file5 &&\n\tgit checkout -b branch2 F &&\n\ttest_commit I file6 &&\n\tgit checkout -b conflict-branch A &&\n\ttest_commit one conflict &&\n\ttest_commit two conflict &&\n\ttest_commit three conflict &&\n\ttest_commit four conflict &&\n\tgit checkout -b no-conflict-branch A &&\n\ttest_commit J fileJ &&\n\ttest_commit K fileK &&\n\ttest_commit L fileL &&\n\ttest_commit M fileM &&\n\tgit checkout -b no-ff-branch A &&\n\ttest_commit N fileN &&\n\ttest_commit O fileO &&\n\ttest_commit P fileP\n\n[master# GETTEXT POISON # 6e62bf8] A\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file1\n[master 313fe96] B\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[master d0f65f2] C\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file2\n[master 0547e3f] D\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[master 8f99a4f] E\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file3\n# GETTEXT POISON #[branch1 cfefd94] F\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file4\n[branch1 83751a6] G\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[branch1 4373208] H\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file5\n# GETTEXT POISON #[branch2 615be62] I\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file6\n# GETTEXT POISON #[conflict-branch b895952] one\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 conflict\n[conflict-branch 766a798] two\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[conflict-branch 1eadf03] three\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[conflict-branch f91a2b3] four\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n# GETTEXT POISON #[no-conflict-branch 808874f] J\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileJ\n[no-conflict-branch 265b89e] K\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileK\n[no-conflict-branch 6b0f5e6] L\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileL\n[no-conflict-branch 3389558] M\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileM\n# GETTEXT POISON #[no-ff-branch 53b4423] N\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileN\n[no-ff-branch cc47714] O\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileO\n[no-ff-branch faef1a5] P\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 fileP\nok 1 - setup\n\nexpecting success: \n\tgit checkout -b emptybranch master &&\n\tgit commit --allow-empty -m \"empty\" &&\n\tgit rebase --keep-empty -i HEAD~2 &&\n\tgit log --oneline >actual &&\n\ttest_line_count = 6 actual\n\n# GETTEXT POISON #[emptybranch da33401] empty\n Author: A U Thor \nSuccessfully rebased and updated refs/heads/emptybranch.\nok 2 - rebase --keep-empty\n\nexpecting success: \n\tgit checkout master &&\n\t(\n\tset_fake_editor &&\n\tFAKE_LINES=\"1 exec_>touch-one\n\t\t2 exec_>touch-two exec_false exec_>touch-three\n\t\t3 4 exec_>\\\"touch-file__name_with_spaces\\\";_>touch-after-semicolon 5\" &&\n\texport FAKE_LINES &&\n\ttest_must_fail git rebase -i A\n\t) &&\n\ttest_path_is_file touch-one &&\n\ttest_path_is_file touch-two &&\n\ttest_path_is_missing touch-three \" (should have stopped before)\" &&\n\ttest_cmp_rev C HEAD &&\n\tgit rebase --continue &&\n\ttest_path_is_file touch-three &&\n\ttest_path_is_file \"touch-file name with spaces\" &&\n\ttest_path_is_file touch-after-semicolon &&\n\ttest_cmp_rev master HEAD &&\n\trm -f touch-*\n\n# GETTEXT POISON #rebase -i script before editing:\npick 313fe96 B\npick d0f65f2 C\npick 0547e3f D\npick 8f99a4f E\n\nrebase -i script after editing:\npick 313fe96 B\nexec >touch-one\npick d0f65f2 C\nexec >touch-two\nexec false\nexec >touch-three\npick 0547e3f D\npick 8f99a4f E\nexec >\"touch-file name with spaces\"; >touch-after-semicolon\nRebasing (2/9)Executing: >touch-one\nRebasing (3/9)Rebasing (4/9)Executing: >touch-two\nRebasing (5/9)Executing: false\nwarning: # GETTEXT POISON #\nRebasing (6/9)Executing: >touch-three\nRebasing (7/9)Rebasing (8/9)Rebasing (9/9)Executing: >\"touch-file name with spaces\"; >touch-after-semicolon\nSuccessfully rebased and updated refs/heads/master.\nok 3 - rebase -i with the exec command\n\nexpecting success: \n\tgit checkout master &&\n\tmkdir subdir && (cd subdir &&\n\tset_fake_editor &&\n\tFAKE_LINES=\"1 exec_>touch-subdir\" \\\n\t\tgit rebase -i HEAD^\n\t) &&\n\ttest_path_is_file touch-subdir &&\n\trm -fr subdir\n\n# GETTEXT POISON #rebase -i script before editing:\npick 8f99a4f E\n\nrebase -i script after editing:\npick 8f99a4f E\nexec >touch-subdir\nRebasing (2/2)Executing: >touch-subdir\nSuccessfully rebased and updated refs/heads/master.\nok 4 - rebase -i with the exec command runs from tree root\n\nexpecting success: \n\tgit checkout master &&\n\tset_fake_editor &&\n\ttest_must_fail env FAKE_LINES=\"exec_echo_foo_>file1 1\" git rebase -i HEAD^ &&\n\ttest_cmp_rev master^ HEAD &&\n\tgit reset --hard &&\n\tgit rebase --continue\n\n# GETTEXT POISON #rebase -i script before editing:\npick 8f99a4f E\n\nrebase -i script after editing:\nexec echo foo >file1\npick 8f99a4f E\nRebasing (1/2)Executing: echo foo >file1\nerror: # GETTEXT POISON #\nwarning: # GETTEXT POISON #\n# GETTEXT POISON # D\nRebasing (2/2)Successfully rebased and updated refs/heads/master.\nok 5 - rebase -i with the exec command checks tree cleanness\n\nexpecting success: \n\tgit checkout master &&\n\ttest_when_finished \"git rebase --abort\" &&\n\tset_fake_editor &&\n\ttest_must_fail env FAKE_LINES=\"exec_this-command-does-not-exist 1\" \\\n\tgit rebase -i HEAD^ >actual 2>&1 &&\n\t! grep \"Maybe git-rebase is broken\" actual\n\n# GETTEXT POISON #ok 6 - rebase -i with exec of inexistent command\n\nexpecting success: \n\tgit checkout branch2 &&\n\tset_fake_editor &&\n\tgit rebase -i F &&\n\ttest \"$(git symbolic-ref -q HEAD)\" = \"refs/heads/branch2\" &&\n\ttest $(git rev-parse I) = $(git rev-parse HEAD)\n\n# GETTEXT POISON #Successfully rebased and updated refs/heads/branch2.\nok 7 - no changes are a nop\n\nexpecting success: \n\tgit checkout -b dead-end &&\n\tgit rm file6 &&\n\tgit commit -m \"stop here\" &&\n\tset_fake_editor &&\n\tgit rebase -i F branch2 &&\n\ttest \"$(git symbolic-ref -q HEAD)\" = \"refs/heads/branch2\" &&\n\ttest $(git rev-parse I) = $(git rev-parse branch2) &&\n\ttest $(git rev-parse I) = $(git rev-parse HEAD)\n\n# GETTEXT POISON #rm 'file6'\n[dead-end f814f58] stop here\n Author: A U Thor \n 1 file changed, 1 deletion(-)\n delete mode 100644 file6\nSuccessfully rebased and updated refs/heads/branch2.\nok 8 - test the [branch] option\n\nexpecting success: \n\tgit checkout -b test-onto branch2 &&\n\tset_fake_editor &&\n\tgit rebase -i --onto branch1 F &&\n\ttest \"$(git symbolic-ref -q HEAD)\" = \"refs/heads/test-onto\" &&\n\ttest $(git rev-parse HEAD^) = $(git rev-parse branch1) &&\n\ttest $(git rev-parse I) = $(git rev-parse branch2)\n\n# GETTEXT POISON #Rebasing (1/1)Successfully rebased and updated refs/heads/test-onto.\nok 9 - test --onto \n\nexpecting success: \n\tgit checkout branch1 &&\n\tgit tag original-branch1 &&\n\tset_fake_editor &&\n\tgit rebase -i branch2 &&\n\ttest file6 = $(git diff --name-only original-branch1) &&\n\ttest \"$(git symbolic-ref -q HEAD)\" = \"refs/heads/branch1\" &&\n\ttest $(git rev-parse I) = $(git rev-parse branch2) &&\n\ttest $(git rev-parse I) = $(git rev-parse HEAD~2)\n\n# GETTEXT POISON #Rebasing (1/2)Rebasing (2/2)Successfully rebased and updated refs/heads/branch1.\nok 10 - rebase on top of a non-conflicting commit\n\nexpecting success: \n\ttest $(git rev-parse branch1@{1}) = $(git rev-parse original-branch1)\n\nok 11 - reflog for the branch shows state before rebase\n\nexpecting success: \n\tprintf \"rebase -i (finish): refs/heads/branch1 onto %s\\n\" \\\n\t\t\"$(git rev-parse branch2)\" >expected &&\n\tgit log -g --pretty=%gs -1 refs/heads/branch1 >actual &&\n\ttest_cmp expected actual\n\nok 12 - reflog for the branch shows correct finish message\n\nexpecting success: \n\tset_fake_editor &&\n\tFAKE_LINES=\"2 1\" git rebase -i HEAD~2 &&\n\ttest H = $(git cat-file commit HEAD^ | sed -ne \\$p) &&\n\ttest G = $(git cat-file commit HEAD | sed -ne \\$p)\n\nrebase -i script before editing:\npick ae8f65e G\npick f5f5249 H\n\nrebase -i script after editing:\npick f5f5249 H\npick ae8f65e G\nRebasing (1/2)Rebasing (2/2)Successfully rebased and updated refs/heads/branch1.\nok 13 - exchange two commits\n\nexpecting success: \n\tgit tag new-branch1 &&\n\tset_fake_editor &&\n\ttest_must_fail git rebase -i master &&\n\ttest \"$(git rev-parse HEAD~3)\" = \"$(git rev-parse master)\" &&\n\ttest_cmp expect .git/rebase-merge/patch &&\n\ttest_cmp expect2 file1 &&\n\ttest \"$(git diff --name-status |\n\t\tsed -n -e \"/^U/s/^U[^a-z]*//p\")\" = file1 &&\n\ttest 4 = $(grep -v \"^#\" < .git/rebase-merge/done | wc -l) &&\n\ttest 0 = $(grep -c \"^[^#]\" < .git/rebase-merge/git-rebase-todo)\n\nRebasing (1/4)Rebasing (2/4)Rebasing (3/4)Rebasing (4/4)error: # GETTEXT POISON #\n\n# GETTEXT POISON #\n\nCould not apply 5d18e54... G\n# GETTEXT POISON #\n# GETTEXT POISON #\nok 14 - stop on conflicting pick\n\nexpecting success: \n\tgit rebase --abort &&\n\ttest $(git rev-parse new-branch1) = $(git rev-parse HEAD) &&\n\ttest \"$(git symbolic-ref -q HEAD)\" = \"refs/heads/branch1\" &&\n\ttest_path_is_missing .git/rebase-merge\n\nok 15 - abort\n\nexpecting success: \n\tgit rm --cached file1 &&\n\tgit commit -m \"remove file in base\" &&\n\tset_fake_editor &&\n\ttest_must_fail git rebase -i master > output 2>&1 &&\n\ttest_i18ngrep \"The following untracked working tree files would be overwritten by checkout:\" \\\n\t\toutput &&\n\ttest_i18ngrep \"file1\" output &&\n\ttest_path_is_missing .git/rebase-merge &&\n\tgit reset --hard HEAD^\n\nrm 'file1'\n[branch1 2dd5570] remove file in base\n Author: A U Thor \n 1 file changed, 1 deletion(-)\n delete mode 100644 file1\n# GETTEXT POISON # G\nok 16 - abort with error when new base cannot be checked out\n\nexpecting success: \n\techo A > file7 &&\n\tgit add file7 &&\n\ttest_tick &&\n\tGIT_AUTHOR_NAME=\"Twerp Snog\" git commit -m \"different author\" &&\n\tgit tag twerp &&\n\tset_fake_editor &&\n\tgit rebase -i --onto master HEAD^ &&\n\tgit show HEAD | grep \"^Author: Twerp Snog\"\n\n[branch1 2596307] different author\n Author: Twerp Snog \n 1 file changed, 1 insertion(+)\n create mode 100644 file7\nRebasing (1/1)Successfully rebased and updated refs/heads/branch1.\nAuthor: Twerp Snog \nok 17 - retain authorship\n\nexpecting success: \n\tgit reset --hard twerp &&\n\ttest_commit a conflict a conflict-a &&\n\tgit reset --hard twerp &&\n\tGIT_AUTHOR_NAME=AttributeMe \\\n\ttest_commit b conflict b conflict-b &&\n\tset_fake_editor &&\n\ttest_must_fail git rebase -i conflict-a &&\n\techo resolved >conflict &&\n\tgit add conflict &&\n\tgit rebase --continue &&\n\ttest $(git rev-parse conflict-a^0) = $(git rev-parse HEAD^) &&\n\tgit show >out &&\n\tgrep AttributeMe out\n\n# GETTEXT POISON # different author\n[branch1 748a43d] a\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 conflict\n# GETTEXT POISON # different author\n[branch1 34d1a6c] b\n Author: AttributeMe \n 1 file changed, 1 insertion(+)\n create mode 100644 conflict\nRebasing (1/1)error: # GETTEXT POISON #\n\n# GETTEXT POISON #\n\nCould not apply 34d1a6c... b\n# GETTEXT POISON #\n# GETTEXT POISON #\n[# GETTEXT POISON # 7866b12] b\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\nSuccessfully rebased and updated refs/heads/branch1.\nAuthor: AttributeMe \nok 18 - retain authorship w/ conflicts\n\nexpecting success: \n\tgit reset --hard twerp &&\n\techo B > file7 &&\n\ttest_tick &&\n\tGIT_AUTHOR_NAME=\"Nitfol\" git commit -m \"nitfol\" file7 &&\n\techo \"******************************\" &&\n\tset_fake_editor &&\n\tFAKE_LINES=\"1 squash 2\" EXPECT_HEADER_COUNT=2 \\\n\t\tgit rebase -i --onto master HEAD~2 &&\n\ttest B = $(cat file7) &&\n\ttest $(git rev-parse HEAD^) = $(git rev-parse master)\n\n# GETTEXT POISON # different author\n[branch1 cdf577a] nitfol\n Author: Nitfol \n 1 file changed, 1 insertion(+), 1 deletion(-)\n******************************\nrebase -i script before editing:\npick 2596307 different author\npick cdf577a nitfol\n\nrebase -i script after editing:\npick 2596307 different author\nsquash cdf577a nitfol\nRebasing (1/2)Rebasing (2/2)[# GETTEXT POISON # d2d5ba7] different author\n Author: Twerp Snog \n Date: Thu Apr 7 15:33:13 2005 -0700\n 1 file changed, 1 insertion(+)\n create mode 100644 file7\nSuccessfully rebased and updated refs/heads/branch1.\nok 19 - squash\n\nexpecting success: \n\tgit show HEAD | grep \"^Author: Twerp Snog\"\n\nAuthor: Twerp Snog \nok 20 - retain authorship when squashing\n\nexpecting success: \n\tHEAD=$(git rev-parse HEAD) &&\n\tset_fake_editor &&\n\tgit rebase -i -p HEAD^ &&\n\tgit update-index --refresh &&\n\tgit diff-files --quiet &&\n\tgit diff-index --quiet --cached HEAD -- &&\n\ttest $HEAD = $(git rev-parse HEAD)\n\n# GETTEXT POISON ## GETTEXT POISON #\nok 21 - -p handles \"no changes\" gracefully\n\nchecking known breakage: \n\tgit checkout H &&\n\tset_fake_editor &&\n\tFAKE_LINES=\"2 1\" git rebase -i -p HEAD~2 &&\n\ttest H = $(git cat-file commit HEAD^ | sed -ne \\$p) &&\n\ttest G = $(git cat-file commit HEAD | sed -ne \\$p)\n\n# GETTEXT POISON ## GETTEXT POISON # 4373208... H\nrebase -i script before editing:\npick 83751a6 G\npick 4373208 H\n\nrebase -i script after editing:\npick 4373208 H\npick 83751a6 G\n# GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON #\nnot ok 22 - exchange two commits with -p # TODO known breakage\n\nexpecting success: \n\tgit checkout -b to-be-preserved master^ &&\n\t: > unrelated-file &&\n\tgit add unrelated-file &&\n\ttest_tick &&\n\tgit commit -m \"unrelated\" &&\n\tgit checkout -b another-branch master &&\n\techo B > file1 &&\n\ttest_tick &&\n\tgit commit -m J file1 &&\n\ttest_tick &&\n\tgit merge to-be-preserved &&\n\techo C > file1 &&\n\ttest_tick &&\n\tgit commit -m K file1 &&\n\techo D > file1 &&\n\ttest_tick &&\n\tgit commit -m L1 file1 &&\n\tgit checkout HEAD^ &&\n\techo 1 > unrelated-file &&\n\ttest_tick &&\n\tgit commit -m L2 unrelated-file &&\n\ttest_tick &&\n\tgit merge another-branch &&\n\techo E > file1 &&\n\ttest_tick &&\n\tgit commit -m M file1 &&\n\tgit checkout -b to-be-rebased &&\n\ttest_tick &&\n\tset_fake_editor &&\n\tgit rebase -i -p --onto branch1 master &&\n\tgit update-index --refresh &&\n\tgit diff-files --quiet &&\n\tgit diff-index --quiet --cached HEAD -- &&\n\ttest $(git rev-parse HEAD~6) = $(git rev-parse branch1) &&\n\ttest $(git rev-parse HEAD~4^2) = $(git rev-parse to-be-preserved) &&\n\ttest $(git rev-parse HEAD^^2^) = $(git rev-parse HEAD^^^) &&\n\ttest $(git show HEAD~5:file1) = B &&\n\ttest $(git show HEAD~3:file1) = C &&\n\ttest $(git show HEAD:file1) = E &&\n\ttest $(git show HEAD:unrelated-file) = 1\n\n# GETTEXT POISON # 83751a6... G\n# GETTEXT POISON #[to-be-preserved 4b3f608] unrelated\n Author: AttributeMe \n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 unrelated-file\n# GETTEXT POISON #[another-branch 8e3f1bd] J\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\n# GETTEXT POISON #\n8e3f1bd J\nvirtual to-be-preserved\n# GETTEXT POISON #\n0547e3f D\nMerge made by the 'recursive' strategy.\n unrelated-file | 0\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 unrelated-file\n[another-branch 0f839ac] K\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\n[another-branch 916bd1f] L1\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\n# GETTEXT POISON ## GETTEXT POISON # 0f839ac... K\n[# GETTEXT POISON # 8fa3ce5] L2\n Author: AttributeMe \n 1 file changed, 1 insertion(+)\n# GETTEXT POISON #\n8fa3ce5 L2\nvirtual another-branch\n# GETTEXT POISON #\n0f839ac K\nMerge made by the 'recursive' strategy.\n file1 | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n[# GETTEXT POISON # e12d8fb] M\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\n# GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON #\nok 23 - preserve merges with -p\n\nexpecting success: \n\tset_fake_editor &&\n\tFAKE_LINES=\"1 2 edit 3 4\" git rebase -i -p HEAD~3 &&\n\techo 2 > unrelated-file &&\n\ttest_tick &&\n\tgit commit -m L2-modified --amend unrelated-file &&\n\tgit rebase --continue &&\n\tgit update-index --refresh &&\n\tgit diff-files --quiet &&\n\tgit diff-index --quiet --cached HEAD -- &&\n\ttest $(git show HEAD:unrelated-file) = 2\n\nrebase -i script before editing:\npick 60cb1bd L2\npick f2d0f15 L1\npick 8b9d7f7 Merge branch 'another-branch' into HEAD\npick ecf20bb M\n\nrebase -i script after editing:\npick 60cb1bd L2\npick f2d0f15 L1\nedit 8b9d7f7 Merge branch 'another-branch' into HEAD\npick ecf20bb M\n# GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON ## GETTEXT POISON #\n# GETTEXT POISON #\n\n[# GETTEXT POISON # 82f9bab] L2-modified\n Author: AttributeMe \n Date: Thu Apr 7 15:43:13 2005 -0700\n# GETTEXT POISON ## GETTEXT POISON #\nok 24 - edit ancestor with -p\n\nexpecting success: \n\ttest_tick &&\n\tset_fake_editor &&\n\ttest_must_fail git rebase -i --onto new-branch1 HEAD^ &&\n\techo resolved > file1 &&\n\tgit add file1 &&\n\tFAKE_COMMIT_MESSAGE=\"chouette!\" git rebase --continue &&\n\ttest $(git rev-parse HEAD^) = $(git rev-parse new-branch1) &&\n\tgit show HEAD | grep chouette\n\nRebasing (1/1)error: # GETTEXT POISON #\n\n# GETTEXT POISON #\n\nCould not apply 23e2f4c... M\n# GETTEXT POISON #\n# GETTEXT POISON #\n[# GETTEXT POISON # be87a39] chouette!\n Author: AttributeMe \n 1 file changed, 1 insertion(+), 1 deletion(-)\nSuccessfully rebased and updated refs/heads/to-be-rebased.\n chouette!\nok 25 - --continue tries to commit\n\nexpecting success: \n\tgit reset --hard master@{1} &&\n\ttest_tick &&\n\tset_fake_editor &&\n\ttest_must_fail git rebase -v -i --onto new-branch1 HEAD^ &&\n\techo resolved > file1 &&\n\tgit add file1 &&\n\tgit rebase --continue > output &&\n\tgrep \"^ file1 | 2 +-$\" output\n\n# GETTEXT POISON # D\n# GETTEXT POISON #\n file1 | 2 +-\n file4 | 1 +\n file5 | 1 +\n file6 | 1 +\n 4 files changed, 4 insertions(+), 1 deletion(-)\n create mode 100644 file4\n create mode 100644 file5\n create mode 100644 file6\n# GETTEXT POISON ## GETTEXT POISON # 5d18e54... G\nRebasing (1/1)\nerror: # GETTEXT POISON #\n\n# GETTEXT POISON #\n\nCould not apply 0547e3f... D\n# GETTEXT POISON #\n# GETTEXT POISON #\nSuccessfully rebased and updated refs/heads/to-be-rebased.\n file1 | 2 +-\nok 26 - verbose flag is heeded, even after --continue\n\nexpecting success: \n\tbase=$(git rev-parse HEAD~4) &&\n\tset_fake_editor &&\n\tFAKE_COMMIT_AMEND=\"ONCE\" FAKE_LINES=\"1 squash 2 squash 3 squash 4\" \\\n\t\tEXPECT_HEADER_COUNT=4 \\\n\t\tgit rebase -i $base &&\n\ttest $base = $(git rev-parse HEAD^) &&\n\ttest 1 = $(git show | grep ONCE | wc -l)\n\nrebase -i script before editing:\npick 615be62 I\npick 0626e8d H\npick 5d18e54 G\npick 2e6badc D\n\nrebase -i script after editing:\npick 615be62 I\nsquash 0626e8d H\nsquash 5d18e54 G\nsquash 2e6badc D\nRebasing (2/4)Rebasing (3/4)error: # GETTEXT POISON #\nCould not apply 5d18e54... G\nnot ok 27 - multi-squash only fires up editor once\n#\t\n#\t\tbase=$(git rev-parse HEAD~4) &&\n#\t\tset_fake_editor &&\n#\t\tFAKE_COMMIT_AMEND=\"ONCE\" FAKE_LINES=\"1 squash 2 squash 3 squash 4\" \\\n#\t\t\tEXPECT_HEADER_COUNT=4 \\\n#\t\t\tgit rebase -i $base &&\n#\t\ttest $base = $(git rev-parse HEAD^) &&\n#\t\ttest 1 = $(git show | grep ONCE | wc -l)\n#\t\n"},{"id":"323121","messageId":"xmqqr2yaedsv.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"xmqqfueqfxfv.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-23T18:53:20Z","receivedAt":"2017-06-23T18:53:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> 3404 needs a similar fix-up for the series to be able to stand on\n> its own. Alternatively, at least we need to understand what in 'pu'\n> makes the result of the merge pass---the symptom indicates that this\n> topic cannot be merged to a released version without that unknown\n> other topic in 'pu' merged if we want to keep POISON build passing\n> the tests.\n\nAh, no worries. I think I figured it out. \n\nThe topic \"rebase -i regression fix\", which this \"regression fix\ntests\" builds on, is queued on an older codebase than 0d75bfe6\n(\"tests: fix tests broken under GETTEXT_POISON=YesPlease\",\n2017-05-05); it is natural these old test breakages can be seen when\nthe topic is tested alone.\n\nSo we can safely merge this topic down.\n\nThanks for prodding me to take a deeper look.\n\n\n"},{"id":"323124","messageId":"xmqqmv8yedg0.fsf@gitster.mtv.corp.google.com","threadId":"46075","inReplyTo":"xmqqfueqfxfv.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-23T19:01:03Z","receivedAt":"2017-06-23T19:01:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> For 3420, I can wrap the two-liner patch I showed here earlier into\n> a commit on top of the series. \n\nSo, here is what I'll queue on top before merging the topic down to\n'master'.\n\n-- >8 --\nSubject: [PATCH] t3420: fix under GETTEXT_POISON build\n\nNewly added tests to t3420 in this series prepare expected\nhuman-readable output from \"git rebase -i\" and then compare the\nactual output with it. As the output from the command is designed\nto go through i18n/l10n, we need to use test_i18ncmp to tell\nGETTEXT_POISON build that it is OK the output does not match.\n\nSigned-off-by: Junio C Hamano \n---\n t/t3420-rebase-autostash.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\nindex 6826c38cbd..e243700660 100755\n--- a/t/t3420-rebase-autostash.sh\n+++ b/t/t3420-rebase-autostash.sh\n@@ -178,7 +178,7 @@ testrebase () {\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n \t\tcreate_expected_success_$suffix &&\n-\t\ttest_cmp expected actual\n+\t\ttest_i18ncmp expected actual\n \t'\n \n \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n@@ -275,7 +275,7 @@ testrebase () {\n \t\ttest_when_finished git branch -D rebased-feature-branch &&\n \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n \t\tcreate_expected_failure_$suffix &&\n-\t\ttest_cmp expected actual\n+\t\ttest_i18ncmp expected actual\n \t'\n }\n \n-- \n2.13.1-678-g93553a431c\n\n"},{"id":"323260","messageId":"955e36fb-a6e9-51d4-84b7-b33859c3fe36@talktalk.net","threadId":"46075","inReplyTo":"xmqqr2yaedsv.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-26T09:17:42Z","receivedAt":"2017-06-26T09:17:51Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 23/06/17 19:53, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> 3404 needs a similar fix-up for the series to be able to stand on\n>> its own. Alternatively, at least we need to understand what in 'pu'\n>> makes the result of the merge pass---the symptom indicates that this\n>> topic cannot be merged to a released version without that unknown\n>> other topic in 'pu' merged if we want to keep POISON build passing\n>> the tests.\n> \n> Ah, no worries. I think I figured it out. \n> \n> The topic \"rebase -i regression fix\", which this \"regression fix\n> tests\" builds on, is queued on an older codebase than 0d75bfe6\n> (\"tests: fix tests broken under GETTEXT_POISON=YesPlease\",\n> 2017-05-05); it is natural these old test breakages can be seen when\n> the topic is tested alone.\n\nOh, that explains it, I was pretty sure the reflog messages were not\ntranslated so couldn't understand why it would fail under\nGETTEXT_POISON=YesPlease\n\n> So we can safely merge this topic down.\n\nThat's great, thanks for taking the time to track down the reason for\nthe test failure\n\nBest Wishes\n\nPhillip\n\n\n"},{"id":"323261","messageId":"5858ba2d-b88d-c2f1-2877-df0d1e8abc64@talktalk.net","threadId":"46075","inReplyTo":"xmqqmv8yedg0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-06-26T09:23:12Z","receivedAt":"2017-06-26T09:23:19Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 23/06/17 20:01, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> For 3420, I can wrap the two-liner patch I showed here earlier into\n>> a commit on top of the series. \n> \n> So, here is what I'll queue on top before merging the topic down to\n> 'master'.\n\nThanks for creating this fixup, I'll remember to think about\nGETTEXT_POISON when I'm writing tests in the future.\n\n> -- >8 --\n> Subject: [PATCH] t3420: fix under GETTEXT_POISON build\n> \n> Newly added tests to t3420 in this series prepare expected\n> human-readable output from \"git rebase -i\" and then compare the\n> actual output with it. As the output from the command is designed\n> to go through i18n/l10n, we need to use test_i18ncmp to tell\n> GETTEXT_POISON build that it is OK the output does not match.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> t/t3420-rebase-autostash.sh | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh\n> index 6826c38cbd..e243700660 100755\n> --- a/t/t3420-rebase-autostash.sh\n> +++ b/t/t3420-rebase-autostash.sh\n> @@ -178,7 +178,7 @@ testrebase () {\n> \t\ttest_when_finished git branch -D rebased-feature-branch &&\n> \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n> \t\tcreate_expected_success_$suffix &&\n> -\t\ttest_cmp expected actual\n> +\t\ttest_i18ncmp expected actual\n> \t'\n> \n> \ttest_expect_success \"rebase$type: dirty index, non-conflicting rebase\" '\n> @@ -275,7 +275,7 @@ testrebase () {\n> \t\ttest_when_finished git branch -D rebased-feature-branch &&\n> \t\tsuffix=${type#\\ --} && suffix=${suffix:-am} &&\n> \t\tcreate_expected_failure_$suffix &&\n> -\t\ttest_cmp expected actual\n> +\t\ttest_i18ncmp expected actual\n> \t'\n> }\n> \n> \n\n"}]}