{"thread":{"id":"36578","subject":"[PATCH 0/4] remote-hg: more improvements","startedAt":"2014-05-04T02:16:50Z","lastAt":"2014-05-15T06:03:32Z","messageCount":49,"participants":["Felipe Contreras","Eric Sunshine","Junio C Hamano","James Denholm","Philippe Vaucher","David Kastrup"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"240652","messageId":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","threadId":"36578","inReplyTo":null,"subject":"[PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T02:16:50Z","receivedAt":"2014-05-04T02:16:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n\n\nFelipe Contreras (4):\n remote-hg: add more tests\n t: remote-hg: add file operation tests\n t: remote-hg: trivial cleanups and fixes\n remote-hg: add support for hg v3.0\n\n contrib/remote-helpers/git-remote-hg | 6 +-\n contrib/remote-helpers/test-hg.sh | 240 ++++++++++++++++++++++++++++++++++-\n 2 files changed, 238 insertions(+), 8 deletions(-)\n\n-- \n1.9.2+fc1.20.g204a630\n"},{"id":"240656","messageId":"1399169814-20201-2-git-send-email-felipe.contreras@gmail.com","threadId":"36578","inReplyTo":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/4] remote-hg: add more tests","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T02:16:51Z","receivedAt":"2014-05-04T02:16:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Inspired by the tests in gitifyhg.\n\nOne test is failing, but that's because of a limitation of\nremote-helpers.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/test-hg.sh | 150 ++++++++++++++++++++++++++++++++++++++\n 1 file changed, 150 insertions(+)\n\ndiff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\nindex 7d90056..33a434d 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/contrib/remote-helpers/test-hg.sh\n@@ -845,4 +845,154 @@ test_expect_success 'clone remote with generic null bookmark, then push to the b\n \t)\n '\n \n+test_expect_success 'notes' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one &&\n+\techo two > content &&\n+\thg commit -m two\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\thg -R hgrepo log --template \"{node}\\n\\n\" > expected &&\n+\tgit --git-dir=gitrepo/.git log --pretty=\"tformat:%N\" --notes=hg > actual &&\n+\ttest_cmp expected actual\n+'\n+\n+test_expect_failure 'push updates notes' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\n+\t(\n+\tcd gitrepo &&\n+\techo two > content &&\n+\tgit commit -a -m two\n+\tgit push\n+\t) &&\n+\n+\thg -R hgrepo log --template \"{node}\\n\\n\" > expected &&\n+\tgit --git-dir=gitrepo/.git log --pretty=\"tformat:%N\" --notes=hg > actual &&\n+\ttest_cmp expected actual\n+'\n+\n+test_expect_success 'pull tags' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\n+\t(cd hgrepo && hg tag v1.0) &&\n+\t(cd gitrepo && git pull) &&\n+\n+\techo \"v1.0\" > expected &&\n+\tgit --git-dir=gitrepo/.git tag > actual &&\n+\ttest_cmp expected actual\n+'\n+\n+test_expect_success 'push merged named branch' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one &&\n+\thg branch feature &&\n+\techo two > content &&\n+\thg commit -m two &&\n+\thg update default &&\n+\techo three > content &&\n+\thg commit -m three\n+\t) &&\n+\n+\t(\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcd gitrepo &&\n+\tgit merge -m Merge -Xtheirs origin/branches/feature &&\n+\tgit push\n+\t) &&\n+\n+\tcat > expected <<-EOF\n+\tMerge\n+\tthree\n+\ttwo\n+\tone\n+\tEOF\n+\thg -R hgrepo log --template \"{desc}\\n\" > actual &&\n+\ttest_cmp expected actual\n+'\n+\n+test_expect_success 'light tag sets author' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one\n+\t) &&\n+\n+\t(\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcd gitrepo &&\n+\tgit tag v1.0 &&\n+\tgit push --tags\n+\t) &&\n+\n+\techo \"C O Mitter \" > expected &&\n+\thg -R hgrepo log --template \"{author}\\n\" -r tip > actual &&\n+\ttest_cmp expected actual\n+'\n+\n+test_expect_success 'push tag different branch' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\techo one > content &&\n+\thg add content &&\n+\thg commit -m one\n+\thg branch feature &&\n+\techo two > content &&\n+\thg commit -m two\n+\t) &&\n+\n+\t(\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcd gitrepo &&\n+\tgit branch &&\n+\tgit checkout branches/feature &&\n+\tgit tag v1.0 &&\n+\tgit push --tags\n+\t) &&\n+\n+\techo feature > expected &&\n+\thg -R hgrepo log --template=\"{branch}\\n\" -r tip > actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_done\n-- \n1.9.2+fc1.20.g204a630\n"},{"id":"240655","messageId":"1399169814-20201-3-git-send-email-felipe.contreras@gmail.com","threadId":"36578","inReplyTo":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/4] t: remote-hg: add file operation tests","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T02:16:52Z","receivedAt":"2014-05-04T02:16:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Inspired by gitifyhg.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/test-hg.sh | 76 +++++++++++++++++++++++++++++++++++++++\n 1 file changed, 76 insertions(+)\n\ndiff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\nindex 33a434d..df09966 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/contrib/remote-helpers/test-hg.sh\n@@ -53,6 +53,17 @@ check_bookmark () {\n \tfi\n }\n \n+check_files () {\n+\tgit --git-dir=$1/.git ls-files > actual &&\n+\tif test $# -gt 1\n+\tthen\n+\t\tprintf \"%s\\n\" \"$2\" > expected\n+\telse\n+\t\t> expected\n+\tfi &&\n+\ttest_cmp expected actual\n+}\n+\n check_push () {\n \texpected_ret=$1 ret=0 ref_ret=0\n \n@@ -995,4 +1006,69 @@ test_expect_success 'push tag different branch' '\n \ttest_cmp expected actual\n '\n \n+test_expect_success 'cloning a removed file works' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\n+\techo test > test_file &&\n+\thg add test_file &&\n+\thg commit -m add &&\n+\n+\thg rm test_file &&\n+\thg commit -m remove\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcheck_files gitrepo\n+'\n+\n+test_expect_success 'cloning a file replaced with a directory' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\n+\techo test > dir_or_file &&\n+\thg add dir_or_file &&\n+\thg commit -m add &&\n+\n+\thg rm dir_or_file &&\n+\tmkdir dir_or_file &&\n+\techo test > dir_or_file/test_file &&\n+\thg add dir_or_file/test_file &&\n+\thg commit -m replase\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcheck_files gitrepo \"dir_or_file/test_file\"\n+'\n+\n+test_expect_success 'clone replace directory with a file' '\n+\ttest_when_finished \"rm -rf hgrepo gitrepo\" &&\n+\n+\t(\n+\thg init hgrepo &&\n+\tcd hgrepo &&\n+\n+\tmkdir dir_or_file &&\n+\techo test > dir_or_file/test_file &&\n+\thg add dir_or_file/test_file &&\n+\thg commit -m add &&\n+\n+\thg rm dir_or_file/test_file &&\n+\techo test > dir_or_file &&\n+\thg add dir_or_file &&\n+\thg commit -m add &&\n+\n+\thg rm dir_or_file\n+\t) &&\n+\n+\tgit clone \"hg::hgrepo\" gitrepo &&\n+\tcheck_files gitrepo \"dir_or_file\"\n+'\n+\n test_done\n-- \n1.9.2+fc1.20.g204a630\n"},{"id":"240653","messageId":"1399169814-20201-4-git-send-email-felipe.contreras@gmail.com","threadId":"36578","inReplyTo":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/4] t: remote-hg: trivial cleanups and fixes","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T02:16:53Z","receivedAt":"2014-05-04T02:16:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"There was a broken && chain, and cat is simpler than echo in a subshell.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/test-hg.sh | 14 +++++++-------\n 1 file changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\nindex df09966..9b9468b 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/contrib/remote-helpers/test-hg.sh\n@@ -25,7 +25,7 @@ fi\n \n check () {\n \techo $3 >expected &&\n-\tgit --git-dir=$1/.git log --format='%s' -1 $2 >actual\n+\tgit --git-dir=$1/.git log --format='%s' -1 $2 >actual &&\n \ttest_cmp expected actual\n }\n \n@@ -103,12 +103,12 @@ check_push () {\n }\n \n setup () {\n-\t(\n-\techo \"[ui]\"\n-\techo \"username = H G Wells \"\n-\techo \"[extensions]\"\n-\techo \"mq =\"\n-\t) >>\"$HOME\"/.hgrc &&\n+\tcat >> \"$HOME\"/.hgrc <<-EOF &&\n+\t[ui]\n+\tusername = H G Wells \n+\t[extensions]\n+\tmq =\n+\tEOF\n \n \tGIT_AUTHOR_DATE=\"2007-01-01 00:00:00 +0230\" &&\n \tGIT_COMMITTER_DATE=\"$GIT_AUTHOR_DATE\" &&\n-- \n1.9.2+fc1.20.g204a630\n"},{"id":"240654","messageId":"1399169814-20201-5-git-send-email-felipe.contreras@gmail.com","threadId":"36578","inReplyTo":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 4/4] remote-hg: add support for hg v3.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T02:16:54Z","receivedAt":"2014-05-04T02:16:54Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 34cda02..8b02803 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -13,6 +13,7 @@\n # \"$GIT_DIR/hg/origin/clone/.hg/\".\n \n from mercurial import hg, ui, bookmarks, context, encoding, node, error, extensions, discovery, util\n+from mercurial import changegroup\n \n import re\n import sys\n@@ -985,7 +986,10 @@ def push_unsafe(repo, remote, parsed_refs, p_revs):\n if not checkheads(repo, remote, p_revs):\n return None\n \n- cg = repo.getbundle('push', heads=list(p_revs), common=common)\n+ if check_version(3, 0):\n+ cg = changegroup.getbundle(repo, 'push', heads=list(p_revs), common=common)\n+ else:\n+ cg = repo.getbundle('push', heads=list(p_revs), common=common)\n \n unbundle = remote.capable('unbundle')\n if unbundle:\n-- \n1.9.2+fc1.20.g204a630\n"},{"id":"240675","messageId":"CAPig+cSP+M_HDaif+Xy-x2tuNcjtemmugSQK2V-jKxup-Nizxw@mail.gmail.com","threadId":"36578","inReplyTo":"1399169814-20201-2-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/4] remote-hg: add more tests","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-05-04T09:40:05Z","receivedAt":"2014-05-04T09:40:05Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, May 3, 2014 at 10:16 PM, Felipe Contreras\n wrote:\n> Inspired by the tests in gitifyhg.\n>\n> One test is failing, but that's because of a limitation of\n> remote-helpers.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> contrib/remote-helpers/test-hg.sh | 150 ++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 150 insertions(+)\n>\n> diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\n> index 7d90056..33a434d 100755\n> --- a/contrib/remote-helpers/test-hg.sh\n> +++ b/contrib/remote-helpers/test-hg.sh\n> @@ -845,4 +845,154 @@ test_expect_success 'clone remote with generic null bookmark, then push to the b\n> )\n> '\n>\n> +test_expect_success 'notes' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one &&\n> + echo two > content &&\n> + hg commit -m two\n> + ) &&\n> +\n> + git clone \"hg::hgrepo\" gitrepo &&\n> + hg -R hgrepo log --template \"{node}\\n\\n\" > expected &&\n> + git --git-dir=gitrepo/.git log --pretty=\"tformat:%N\" --notes=hg > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> +test_expect_failure 'push updates notes' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one\n> + ) &&\n> +\n> + git clone \"hg::hgrepo\" gitrepo &&\n> +\n> + (\n> + cd gitrepo &&\n> + echo two > content &&\n> + git commit -a -m two\n> + git push\n> + ) &&\n> +\n> + hg -R hgrepo log --template \"{node}\\n\\n\" > expected &&\n> + git --git-dir=gitrepo/.git log --pretty=\"tformat:%N\" --notes=hg > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'pull tags' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one\n> + ) &&\n> +\n> + git clone \"hg::hgrepo\" gitrepo &&\n> +\n> + (cd hgrepo && hg tag v1.0) &&\n> + (cd gitrepo && git pull) &&\n> +\n> + echo \"v1.0\" > expected &&\n> + git --git-dir=gitrepo/.git tag > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'push merged named branch' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one &&\n> + hg branch feature &&\n> + echo two > content &&\n> + hg commit -m two &&\n> + hg update default &&\n> + echo three > content &&\n> + hg commit -m three\n> + ) &&\n> +\n> + (\n> + git clone \"hg::hgrepo\" gitrepo &&\n> + cd gitrepo &&\n> + git merge -m Merge -Xtheirs origin/branches/feature &&\n> + git push\n> + ) &&\n> +\n> + cat > expected <<-EOF\n\nBroken &&-chain.\n\n> + Merge\n> + three\n> + two\n> + one\n> + EOF\n> + hg -R hgrepo log --template \"{desc}\\n\" > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'light tag sets author' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one\n> + ) &&\n> +\n> + (\n> + git clone \"hg::hgrepo\" gitrepo &&\n> + cd gitrepo &&\n> + git tag v1.0 &&\n> + git push --tags\n> + ) &&\n> +\n> + echo \"C O Mitter \" > expected &&\n> + hg -R hgrepo log --template \"{author}\\n\" -r tip > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'push tag different branch' '\n> + test_when_finished \"rm -rf hgrepo gitrepo\" &&\n> +\n> + (\n> + hg init hgrepo &&\n> + cd hgrepo &&\n> + echo one > content &&\n> + hg add content &&\n> + hg commit -m one\n> + hg branch feature &&\n> + echo two > content &&\n> + hg commit -m two\n> + ) &&\n> +\n> + (\n> + git clone \"hg::hgrepo\" gitrepo &&\n> + cd gitrepo &&\n> + git branch &&\n> + git checkout branches/feature &&\n> + git tag v1.0 &&\n> + git push --tags\n> + ) &&\n> +\n> + echo feature > expected &&\n> + hg -R hgrepo log --template=\"{branch}\\n\" -r tip > actual &&\n> + test_cmp expected actual\n> +'\n> +\n> test_done\n> --\n> 1.9.2+fc1.20.g204a630\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"240928","messageId":"xmqq8uqdbgqg.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"1399169814-20201-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-07T18:12:23Z","receivedAt":"2014-05-07T18:12:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n\nI think the discussion with John Keeping hints that we shouldn't be\nrushing fc/remote-helpers-hg-bzr-graduation and this does not appear\nto assume the presense of that series, which is good in order to\nmake these fixes jump over them.\n\nI'll queue this separately on a topic based on the tip of\nyesterday's master for now.\n\nOne thing I couldn't read from the proposed log messages was if this\nis meant to work with and tested with both v3.0 and pre-v3.0 Hg, or\nthis is to request others who run pre-v3.0 Hg to test these changes.\n\nFor example, I see\n\n\tfrom mercurial import changegroup\n if check_version(3, 0):\n \tcg = changegroup.getbundle(...)\n\telse:\n \tcg = repo.getbundle(...)\n\nand offhand it was unclear if the unconditional import was a\nmistake.\n\nThanks.\n\n>\n>\n> Felipe Contreras (4):\n> remote-hg: add more tests\n> t: remote-hg: add file operation tests\n> t: remote-hg: trivial cleanups and fixes\n> remote-hg: add support for hg v3.0\n>\n> contrib/remote-helpers/git-remote-hg | 6 +-\n> contrib/remote-helpers/test-hg.sh | 240 ++++++++++++++++++++++++++++++++++-\n> 2 files changed, 238 insertions(+), 8 deletions(-)\n"},{"id":"240935","messageId":"536a83097302f_76ff7a52ec6c@nysa.notmuch","threadId":"36578","inReplyTo":"xmqq8uqdbgqg.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T19:01:29Z","receivedAt":"2014-05-07T19:01:29Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n> \n> I think the discussion with John Keeping hints that we shouldn't be\n> rushing fc/remote-helpers-hg-bzr-graduation\n\nReally? Based on what reasoning? I have proven his reasoning to be\nbasically wrong.\n\n> I'll queue this separately on a topic based on the tip of\n> yesterday's master for now.\n> \n> One thing I couldn't read from the proposed log messages was if this\n> is meant to work with and tested with both v3.0 and pre-v3.0 Hg, or\n> this is to request others who run pre-v3.0 Hg to test these changes.\n> \n> For example, I see\n> \n> \tfrom mercurial import changegroup\n> if check_version(3, 0):\n> \tcg = changegroup.getbundle(...)\n> \telse:\n> \tcg = repo.getbundle(...)\n> \n> and offhand it was unclear if the unconditional import was a\n> mistake.\n\nOf course it wasn't a mistake.\n\n-- \nFelipe Contreras\n"},{"id":"240946","messageId":"xmqqvbth8ha9.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536a83097302f_76ff7a52ec6c@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-07T20:28:46Z","receivedAt":"2014-05-07T20:28:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> \n>> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n>> \n>> I think the discussion with John Keeping hints that we shouldn't be\n>> rushing fc/remote-helpers-hg-bzr-graduation\n>\n> Really? Based on what reasoning? I have proven his reasoning to be\n> basically wrong.\n\nPerhaps s/proven/convinced myself only/; you didn't prove it to me\nand I doubt you proved it to John.\n\n>> For example, I see\n>> \n>> \tfrom mercurial import changegroup\n>> if check_version(3, 0):\n>> \tcg = changegroup.getbundle(...)\n>> \telse:\n>> \tcg = repo.getbundle(...)\n>> \n>> and offhand it was unclear if the unconditional import was a\n>> mistake.\n>\n> Of course it wasn't a mistake.\n\nI doubt about the \"Of course\" part. The first reaction after seeing\nthat the new \"changegroup\" is used only inside check_version(3,0)\nand nowhere else was to wonder if that import is necessary (or even\nsafe) for the pre-v3.0 versions.\n"},{"id":"240955","messageId":"536a999e2c0c_76ff7a52ec1e@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqvbth8ha9.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T20:37:50Z","receivedAt":"2014-05-07T20:37:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> > Really? Based on what reasoning? I have proven his reasoning to be\n> > basically wrong.\n> \n> Perhaps s/proven/convinced myself only/; you didn't prove it to me\n> and I doubt you proved it to John.\n\nAnd you are still conveniently avoiding the question:\n\nBased on what reasoning?\n\n> > Of course it wasn't a mistake.\n> \n> I doubt about the \"Of course\" part. The first reaction after seeing\n> that the new \"changegroup\" is used only inside check_version(3,0)\n> and nowhere else was to wonder if that import is necessary (or even\n> safe) for the pre-v3.0 versions.\n\nI don't care about your first reaction. If that was only present in\nnewer versions, how do you think it would pass the testing on older\nversions?\n\nhttps://travis-ci.org/felipec/git\n\nNormally I would explain the details of why this is the case, and send\nthe crash regresion fix for v2.0 with a clear explanation, but since you\nare adamant in threating git-remote-hg/bzr as just another crappy\ncontrib script that doesn't even have tests like diff-highlight or\nhg-to-git. Why would I care?\n\nThe fact that I'm the maintainer and I say it'ss good should be good\nenough, and if the current version in \"master\" renders unusable the\nexisting Mercurial clones, hey, it's only in contrib, right?\n\n-- \nFelipe Contreras\n"},{"id":"240978","messageId":"xmqqoaz95ees.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536a999e2c0c_76ff7a52ec1e@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-07T23:59:07Z","receivedAt":"2014-05-07T23:59:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> And you are still conveniently avoiding the question:\n>\n> Based on what reasoning?\n\nGo re-read what was already said in the thread. I still think\nremote-hg and remote-bzr can and will flourish on their own merit,\nand unbundling will be better for the end users for the reasons\nstated there already.\n\nHaving said that, I've been thinking (not because of this thread,\nbut because I like imerge better and better these days) that there\nshould be a much better way to have a list of recommended third-party\nplug-ins that enrich the Git ecosystem. We have \n\n https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n\n(Jakub cc'ed as he often nudges those who announce their tools to\nadd an entry there) but honestly, git-scm.com is the first site the\nend users who do not hack on Git would visit, and we probably should\nhave a catalog there (Scott and Peff cc'ed for that site). One way\nto help it may be to add a Documentation/gitthirdparty-tools.txt in\nmy tree that would automatically be pulled into git-scm.com site as\na part of the manual. A richer ecosystem with tools outside my tree\nwould not materialize unless there is such a mechanism to advertise\nthe existence of them, and having to include a copy of each and\nevery third-party tools in my tree and keeping them relatively fresh\nis not going to scale in the long run (Michael and Matthieu Cc'ed as\nI saw exchanges on multimail in a near-by thread).\n\nSuch a file would probably cluster \"plugins\" into different\ncategories (post-receive hooks, remote-helpers, mergetools, etc.)\nand limit the entry descriptions to a single paragraph of several\nlines tops, with URL referring to the third-party maintainer's site\n(e.g. a repository at GitHub).\n\n>> > Of course it wasn't a mistake.\n>> \n>> I doubt about the \"Of course\" part. The first reaction after seeing\n>> that the new \"changegroup\" is used only inside check_version(3,0)\n>> and nowhere else was to wonder if that import is necessary (or even\n>> safe) for the pre-v3.0 versions.\n>\n> I don't care about your first reaction. If that was only present in\n> newer versions, how do you think it would pass the testing on older\n> versions?\n>\n> https://travis-ci.org/felipec/git\n>\n> Normally I would explain the details of why this is the case, and send\n> the crash regresion fix for v2.0 with a clear explanation,...\n\nWithout such an explanation in the log message, how would you expect\nanybody to guess correctly?\n\nSeriously, if you do not care about my first reaction, why do you\neven want to live in my tree?\n\n> The fact that I'm the maintainer and I say it'ss good should be good\n> enough, and if the current version in \"master\" renders unusable the\n> existing Mercurial clones, hey, it's only in contrib, right?\n\nOne potential merit I would see for keeping them in my tree is that\nyour change will see second opinions from others involved in the\nproject (including me), without giving a total rein based on the\nsub-maintainership alone. All the changes from sub-area maintainers\nare vetted by at least two sets of eyeballs that way.\n\nBut after having to deal with you and seeing that you do not take\nconstructive criticism well, I doubt such a possibile merit will\never materialize in the area where you alone work on. Letting you\ndo whatever you want in your own tree may benefit the users of\nremote-hg/remote-bzr better as the (bitter) second best option.\n"},{"id":"240979","messageId":"xmqqha515ebt.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"xmqq8uqdbgqg.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T00:00:54Z","receivedAt":"2014-05-08T00:00:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Felipe Contreras writes:\n>\n>> Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n>\n> I think the discussion with John Keeping hints that we shouldn't be\n> rushing fc/remote-helpers-hg-bzr-graduation and this does not appear\n> to assume the presense of that series, which is good in order to\n> make these fixes jump over them.\n\nWhen merged to a place somewhere early between the next and the pu\nbranches (aka \"the jch branch\", which is the version I usually use\nmyself), this seemed to break t5810, so I did today's integration\ncycle one more time by excluding this topic and then instead queuing\nit near the tip of the pu branch (read: today's 'pu' does not pass\nthe test suite for me).\n\nThere may be some other changes that this series depends on that I\nmay have missed that caused this breakage. Can you take a look?\n\nThanks.\n"},{"id":"240983","messageId":"536ad9601b73b_3caaa612ecdc@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqoaz95ees.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T01:09:52Z","receivedAt":"2014-05-08T01:09:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > And you are still conveniently avoiding the question:\n> >\n> > Based on what reasoning?\n> \n> Go re-read what was already said in the thread.\n\nI already read it, and I already responded.\n\n> I still think remote-hg and remote-bzr can and will flourish on their\n> own merit,\n\nOh, you *think*. Well, what if you are wrong?\n\nOr is that never a possibility? You are always right. Right?\n\n> Having said that, I've been thinking (not because of this thread,\n> but because I like imerge better and better these days) that there\n> should be a much better way to have a list of recommended third-party\n> plug-ins that enrich the Git ecosystem.\n\nIf and when such a mechanism exists, sure, it makes sense to move\nfunctionality like git-p4 and git-remote-hg out of the core and contrib\nareas.\n\nBut in the meantime what is ready for the core should be in the core.\n\n> > Normally I would explain the details of why this is the case, and send\n> > the crash regresion fix for v2.0 with a clear explanation,...\n> \n> Without such an explanation in the log message, how would you expect\n> anybody to guess correctly?\n\nI don't. I told you it wasn't a mistake. If that's not enough for you,\nthat's *your* problem.\n\n*If* git-remote-hg was to be part of the core, then sure, I would care\nthat you didn't understand why the patch is correct, and I would resend\nimmediately what a clear explanation.\n\nBut since it's only part of the contrib area which has such abundant\ncrap without documentation or tests. I do not care.\n\n> Seriously, if you do not care about my first reaction, why do you\n> even want to live in my tree?\n\nAs I already explained; I don't care about your reaction *because* you\ndon't want these tools to live in your tree.\n\n> > The fact that I'm the maintainer and I say it'ss good should be good\n> > enough, and if the current version in \"master\" renders unusable the\n> > existing Mercurial clones, hey, it's only in contrib, right?\n> \n> One potential merit I would see for keeping them in my tree is that\n> your change will see second opinions from others involved in the\n> project (including me), without giving a total rein based on the\n> sub-maintainership alone. All the changes from sub-area maintainers\n> are vetted by at least two sets of eyeballs that way.\n> \n> But after having to deal with you and seeing that you do not take\n> constructive criticism well,\n\nOh, please. Up to the point where you decided unilaterally to move them\nout of the core (they are alread in), all the constructive criticism to\ngit-remote-hg has been addressed properly.\n\nI have spent an absurdely large amount of time working on git-remote-hg,\nand the transport-helper to make sure everything works right. I even started\ngit-remote-bzr just to prove that the Python git_remote_helpers\nframework was not needed, and eventually I made it work better than any\nof the alternatives. I had to fight tooth-and-nail to prove that the\nmsysgit guys were wrong and my patch to handle UNINTERESTING refs\nproperly was right. Not to mention all the tests, the compatibility with\nhg-git, and with gittifyhg, just to prove that my approach was superior\nthan the alternatives.\n\nI addressed every issue reported constructively, every bug report was\nfixed, every patch reviewed and usually improved by me. I made sure\nusers of older versions wouldn't be affected negatively when the marks\nfile was upgraded, and I even setup automatic tests for different\nversions Bazaar and Mercurial that run every time I push to my\nrepository.\n\nIt is *way* beyond the quality of any other tool in 'contrib/' and even\nsome tools in the core, like 'git-request-pull' (which has known bugs),\nand probably even 'git-pt'.\n\nEven you agreed it would be beneficial to move them out of contrib; it\nwould benefit *everyone*. And there was no reason not to.\n\nAnd then some random guy comes with a few bad arguments, and you change\nyour mind.\n\nThat's f*cking double standards. Pure and simple.\n\nIf git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If\ngit-remote-hg belongs in the contrib area, so does git-svn, and git-p4.\n\nAfter all this insane amout of work you are acting as if git-remote-hg\nwasn't ready to move to the core, because I didn't explain *one* commit\nproperly to you (which happened after this bullshit).\n\nIf these helpers are not going to move forward why would I care? Give me\nwhy one good reason why I should give a flying f*ck about the state of\nremote-helpers in *your* tree after this (and BTW as things stand now,\nit's not good).\n\nIt was *your* users who urged me to send my patches upstream.\n\n> I doubt such a possibile merit will ever materialize in the area where\n> you alone work on.\n\nAnd there it is. Ad hominem rationale.\n\n> Letting you do whatever you want in your own tree may benefit the\n> users of remote-hg/remote-bzr better as the (bitter) second best\n> option.\n\nIf and when there is a mechanism promoting out-of-tree tools, that\nmight be the case.\n\nIn the meantime virtually every tool that is worth using lives in\ngit.git and is distributed by default. Everything else is sub-par in the\nminds of Git users.\n\nOne tool being dropped from the tree while other tools remain there is\nnot going to send a positive message to its users.\n\nIf you are so confident git-remote-hg would \"flourish\" out-of-tree, drop\ngit-p4 and git-svn, see what is the reaction.\n\n-- \nFelipe Contreras\n"},{"id":"240986","messageId":"CAHYYfeGvOnonm0fd=Fa9p_if+8dRo2zg_N9c=gjjqyko=ipJag@mail.gmail.com","threadId":"36578","inReplyTo":"536ad9601b73b_3caaa612ecdc@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-05-08T01:34:48Z","receivedAt":"2014-05-08T01:34:48Z","isPatch":true,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe, I would ask, suggest, beg, implore you to calm down. It's\ngenerally not a good plan to alienate the maintainer of a project,\nregardless of the correctness or incorrectness of one's arguments, but I\nfear that's only what you will achieve at the moment.\n\n--\nRegards,\nJames Denholm.\n"},{"id":"240987","messageId":"536adf96f37ec_3caaa612ec69@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqha515ebt.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T01:36:22Z","receivedAt":"2014-05-08T01:36:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Felipe Contreras writes:\n> >\n> >> Here's a bunch of tests more, and a fixes for Mercurial v3.0.\n> >\n> > I think the discussion with John Keeping hints that we shouldn't be\n> > rushing fc/remote-helpers-hg-bzr-graduation and this does not appear\n> > to assume the presense of that series, which is good in order to\n> > make these fixes jump over them.\n> \n> When merged to a place somewhere early between the next and the pu\n> branches (aka \"the jch branch\", which is the version I usually use\n> myself), this seemed to break t5810, so I did today's integration\n> cycle one more time by excluding this topic and then instead queuing\n> it near the tip of the pu branch (read: today's 'pu' does not pass\n> the test suite for me).\n> \n> There may be some other changes that this series depends on that I\n> may have missed that caused this breakage. Can you take a look?\n\nI'm such a bad maintainer and I don't take constructive criticism well\nwhy would you expect me to take a look?\n\nAs usual, I did more than take a look and I went ahead to manually test\nwith multiple versions of Mercurial. The problem appears with hg < 2.6.\n\nHere's the fix:\n\n--- a/git-remote-hg.py\n+++ b/git-remote-hg.py\n@@ -905,7 +905,7 @@ def write_tag(repo, tag, node, msg, author):\n try:\n fctx = tip.filectx(f)\n data = fctx.data()\n- except error.ManifestLookupError:\n+ except error.LookupError:\n data = \"\"\n content = data + \"%s %s\\n\" % (node, tag)\n return context.memfilectx(f, content, False, False, None)\n\n-- \nFelipe Contreras\n"},{"id":"241018","messageId":"xmqqtx902k45.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536adf96f37ec_3caaa612ec69@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T18:36:26Z","receivedAt":"2014-05-08T18:36:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> There may be some other changes that this series depends on that I\n>> may have missed that caused this breakage. Can you take a look?\n>\n> I'm such a bad maintainer and I don't take constructive criticism well\n> why would you expect me to take a look?\n\nBecause this was not about maintainership, but was a simple and\nstraight-forward breakage report [*1*]. There was no criticism\ninvolved, constructive or otherwise.\n\nIn other words, I knew that you are capable enough to track down a\nbug in the code you wrote recently that made it violate the\nexpectation you defined in your own tests. There was no room for\ndifferences of opinions to come into play, as it was just between\nyou and your own code.\n\nWhy would I expect otherwise?\n\nDo you want to make it a separate follow-up patch with a log message\nthat explains why it now uses LookupError (not ManifestLookupError),\nor do you want to reroll the original by squashing it? I am guessing\nthat the reason is because in older versions they used LookupError\nbut in recent versions ManifestLookupError which is a subclass is\nthrown instead, and catching the former would cover both cases, so\nif I were to queue it as a separate [PATCH 5/4] fixup, that is how\nI would explain that change.\n\n[Footnote]\n\n*1* .... and a very bad one at that, missing any useful details; I\napologize and blame lack of time for its lousiness.\n\nThanks for working with very little useful information and fixing.\n"},{"id":"241025","messageId":"536be16ba5ef1_3ce710a12ecdb@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqtx902k45.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T19:56:27Z","receivedAt":"2014-05-08T19:56:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> In other words, I knew that you are capable enough to track down a\n> bug in the code you wrote recently that made it violate the\n> expectation you defined in your own tests.\n\nWrong. The code in question was not recent, it was introdued in 1.8.3,\nmore than one year ago.\n\nAnd wrong, it didn't violate the expectation of my own tests.\n\nThe code was simply not exercised in the tests.\n\n> There was no room for differences of opinions to come into play, as it\n> was just between you and your own code.\n> \n> Why would I expect otherwise?\n\nBecause most people take attacks on their code as personal attacks, and\nthey don't fix bugs in their code if they don't like the person\nreporting it.\n\nBut you know I don't take attacks on my code and ideas personally, which\nis more that can be said of most people on the list.\n\n> Do you want to make it a separate follow-up patch with a log message\n> that explains why it now uses LookupError (not ManifestLookupError),\n> or do you want to reroll the original by squashing it?\n\nI don't want to do anything for a \"contrib\" tool.\n\nIt's already broken in v2.0 anyway.\n\n-- \nFelipe Contreras\n"},{"id":"241028","messageId":"536be5feea670_3ce710a12ecc0@nysa.notmuch","threadId":"36578","inReplyTo":"CAHYYfeGvOnonm0fd=Fa9p_if+8dRo2zg_N9c=gjjqyko=ipJag@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T20:15:58Z","receivedAt":"2014-05-08T20:15:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe, I would ask, suggest, beg, implore you to calm down.\n\nI am calmed down. I waited a day before replying to make sure of that.\n\n> It's generally not a good plan to alienate the maintainer of a\n> project, regardless of the correctness or incorrectness of one's\n> arguments, but I fear that's only what you will achieve at the moment.\n\nHe has already alienated me. In fact he asked me before to leave the\nmailing list. And I did for a while.\n\nHowever, at some level he knows my patches are beneficial to the\nproject, so he is applying them again.\n\nEither way it doesn't matter if I'm calmed down or not, abrassive or\ncivil, this ad hominmen double standards bullshit is going to continue.\n\nSee what was his reply to my mail? *Nothing*.\n\nWhat was his reply when I argued if he even admitted he could\npotentially be wrong, and if so would essentially trash a project I've\nworked very hard for? *Nothing*.\n\nWhat was his reply when I argued that git-remote-hg has more quality\nthan all the tools in contrib, even some in the core and therefore\ndoesn't belong there? *Nothing*.\n\nWhat was his reply when I said double standards were applied for\ngit-remote-hg. *Nothing*.\n\nHow about when I argued there was no mechanism for out-of-tree tools to\nbe properly maintained and promoted, and moving tools outside of the\ntree shouldn't be done before that happens? *Nothing*.\n\nWhat did he say when I suggested to move out git-p4 and git-svn, if he\nis so sure important tools can \"flourish\" out-of-tree? *Nothing*.\n\nThe truth is that it doesn't matter how I present my arguments, calmly\nor otherwise. He is *never* going to accept he was wrong, especially not\nwhen that would mean I was right.\n\nDon't expect any more git-remote-hg patches from me. If Junio thinks\nit's just another crappy contrib tool, then I'll threat it as one.\n\nAnd unfortunately Junio would rather let an important part of Git die a\nslow death rather than admit he was wrong. Just watch him ignore the\nproblem.\n\n-- \nFelipe Contreras\n"},{"id":"241044","messageId":"xmqqppjn29o3.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536be16ba5ef1_3ce710a12ecdb@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T22:22:04Z","receivedAt":"2014-05-08T22:22:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> In other words, I knew that you are capable enough to track down a\n>> bug in the code you wrote recently that made it violate the\n>> expectation you defined in your own tests.\n>\n> Wrong. The code in question was not recent, it was introdued in 1.8.3,\n> more than one year ago.\n>\n> And wrong, it didn't violate the expectation of my own tests.\n>\n> The code was simply not exercised in the tests.\n>\n>> There was no room for differences of opinions to come into play, as it\n>> was just between you and your own code.\n\nOK, I misread the blame output---sorry about that.\n\nBut that does not change the fact that your tests caught a bug in\nyour own code, and the issue was solely between you and your own\ncode without involving criticism from anybody, does it?\n\nUnless you count a barf from a rather old version of Mercurial as a\ncriticism, that is.\n\n>> Why would I expect otherwise?\n>>\n> Because most people take attacks on their code as personal attacks, and\n> they don't fix bugs in their code if they don't like the person\n> reporting it.\n>\n> But you know I don't take attacks on my code and ideas personally, which\n> is more that can be said of most people on the list.\n\nJust to make sure new people who may be watching with popcorns in\ntheir hand from sidelines do not get a wrong impression, I do not\nshare your \"most people take attacks ...\" observation.\n\nIn reviews I have seen over the years around here (and also reviews\nat $DAYJOB), I rarely saw such a reaction by the person whose change\nis reviewed. I view this list as very cooperative and productive\nenvironment most of the time.\n\nIn any case, there was not even any attack---it was merely your code\nnot passing your own test on a platform you did not have access to,\nwhich is not something to be upset about.\n\n> I don't want to do anything for a \"contrib\" tool.\n>\n> It's already broken in v2.0 anyway.\n\nYes, this is not even an old regression. If you no longer want to\nhave it in contrib/, I can drop it in future releases (but not in\nv2.0), so that people can find the latest and greatest directly from\nyou. Otherwise, queuing a fix on 'pu' and then to 'next' in\npreparation for an early graduation for the release after v2.0 (and\nas a fix, it may want to go to older maintenance releases) is also\nfine by me.\n"},{"id":"241048","messageId":"536c084ecb546_4f6fd2f30cdd@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqppjn29o3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T22:42:22Z","receivedAt":"2014-05-08T22:42:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n\n> > I don't want to do anything for a \"contrib\" tool.\n> >\n> > It's already broken in v2.0 anyway.\n> \n> Yes, this is not even an old regression.\n\nYes it is. It has nothing to do with with Mercurial v3.0, that's a\nseparate issue. We've been doing a workaround since v1.8.3, and that\nworkaround will break things in v2.0.\n\nI already said this multiple times, but let me be clear once more:\n\nMASTER HAS A REGRESSION (for all versions of Mercurial).\n\n> If you no longer want to have it in contrib/, I can drop it in future\n> releases (but not in v2.0), so that people can find the latest and\n> greatest directly from you. Otherwise, queuing a fix on 'pu' and then\n> to 'next' in preparation for an early graduation for the release after\n> v2.0 (and as a fix, it may want to go to older maintenance releases)\n> is also fine by me.\n\nAre you saying that the graduation plan is going to continue and they\nare going to move out of contrib and be distributed by default?\n\nIf that's the case I'll resume the fixes because the current sitution is\nnot good.\n\n-- \nFelipe Contreras\n"},{"id":"241049","messageId":"xmqqha4z27ly.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536c084ecb546_4f6fd2f30cdd@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T23:06:33Z","receivedAt":"2014-05-08T23:06:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I already said this multiple times, but let me be clear once more:\n>\n> MASTER HAS A REGRESSION (for all versions of Mercurial).\n\nAs you said, that is not a regression, isn't it? It is an old\nbreakage that existed even before 1.9 (was it 1.8.3 or something?)\n\n>> If you no longer want to have it in contrib/, I can drop it in future\n>> releases (but not in v2.0), so that people can find the latest and\n>> greatest directly from you. Otherwise, queuing a fix on 'pu' and then\n>> to 'next' in preparation for an early graduation for the release after\n>> v2.0 (and as a fix, it may want to go to older maintenance releases)\n>> is also fine by me.\n>\n> Are you saying that the graduation plan is going to continue and they\n> are going to move out of contrib and be distributed by default?\n\nI do not think that is going to happen. As we discussed already, I\ndo see merit in unbundling it from my tree. I can keep it in contrib/\nas that is a slight benefit for you (i.e. you can be lock-step with\nGit) but as long as you live in my tree, you need to follow the same\nrelease schedule as the other contributors, which may be detrimental\nto your users, compared to a case where it is unbundled.\n\nI do not see a strong reason to move it out of contrib, either.\n"},{"id":"241050","messageId":"536c15cf8594b_6f3bb152ecb@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqha4z27ly.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T23:39:59Z","receivedAt":"2014-05-08T23:39:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > I already said this multiple times, but let me be clear once more:\n> >\n> > MASTER HAS A REGRESSION (for all versions of Mercurial).\n> \n> As you said, that is not a regression, isn't it? It is an old\n> breakage that existed even before 1.9 (was it 1.8.3 or something?)\n\nNo. It does't happen in 1.9, it will happen in 2.0.\n\nThat's a REGRESSION.\n\n> >> If you no longer want to have it in contrib/, I can drop it in future\n> >> releases (but not in v2.0), so that people can find the latest and\n> >> greatest directly from you. Otherwise, queuing a fix on 'pu' and then\n> >> to 'next' in preparation for an early graduation for the release after\n> >> v2.0 (and as a fix, it may want to go to older maintenance releases)\n> >> is also fine by me.\n> >\n> > Are you saying that the graduation plan is going to continue and they\n> > are going to move out of contrib and be distributed by default?\n> \n> I do not think that is going to happen.\n\nThen I don't understand what you mean by \"graduation\".\n\n> As we discussed already, I do see merit in unbundling it from my tree.\n\nYou are blind. Move git-p4 and git-svn out of your tree.\n\nYou know what will happen.\n\n> I can keep it in contrib/ as that is a slight benefit for you\n\nWhat is the benefit of being in contrib/? Even you yourself argued that\nthere is not much point of 'contrib/' nowadays[1]. The only reason we\nmight want something in contrib/ is so that it has a chance to mature\nbefore becoming part of the core.\n\n> (i.e. you can be lock-step with Git) but as long as you live in my\n> tree, you need to follow the same release schedule as the other\n> contributors, which may be detrimental to your users, compared to a\n> case where it is unbundled.\n\nIt's much more beneficial to *our* users if these tools are distributed\nby default.\n\n> I do not see a strong reason to move it out of contrib, either.\n\nReally? So why did you say this?[2]\n\n> > Either way, I think if things go well, remote-hg will prove it's\n> > worth and move out of contrib and into git's core.\n> \n> That was what you promised when we started carrying it in contrib/; I\n> am still hoping to see it happen when it matures.\n\nJeff said the same thing when he was acting as maintainer[3], and you\ndidn't correct him:\n\n> I would one day like to have it as part of the main distribution, too,\n> but it would be nice to prove its worth in the field for a while\n> first.\n\nAll this time I've been operating under the impression that once\ngit-remote-hg proved itself, it would graduate out of contrib.\n\nSo basically you tricked me, and I wasted insane amounts of time chasing\na target that was impossible to reach.\n\nFuck this.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/220178\n[2] http://article.gmane.org/gmane.comp.version-control.git/220277\n[3] http://article.gmane.org/gmane.comp.version-control.git/208648\n\n-- \nFelipe Contreras\n"},{"id":"241052","messageId":"536c20084d92e_741a161d31094@nysa.notmuch","threadId":"36578","inReplyTo":"536c15cf8594b_6f3bb152ecb@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-09T00:23:36Z","receivedAt":"2014-05-09T00:23:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> Junio C Hamano wrote:\n\n> > I do not see a strong reason to move it out of contrib, either.\n> \n> Really? So why did you say this?[2]\n> \n> > > Either way, I think if things go well, remote-hg will prove it's\n> > > worth and move out of contrib and into git's core.\n> > \n> > That was what you promised when we started carrying it in contrib/; I\n> > am still hoping to see it happen when it matures.\n> \n> Jeff said the same thing when he was acting as maintainer[3], and you\n> didn't correct him:\n> \n> > I would one day like to have it as part of the main distribution, too,\n> > but it would be nice to prove its worth in the field for a while\n> > first.\n> \n> All this time I've been operating under the impression that once\n> git-remote-hg proved itself, it would graduate out of contrib.\n> \n> So basically you tricked me, and I wasted insane amounts of time chasing\n> a target that was impossible to reach.\n\nEven contrib/README says so:\n\n I expect that things that start their life in the contrib/ area\n to graduate out of contrib/ once they mature, either by becoming\n projects on their own, or moving to the toplevel directory. On\n the other hand, I expect I'll be proposing removal of disused\n and inactive ones from time to time.\n\n-- \nFelipe Contreras\n"},{"id":"241178","messageId":"xmqq61le27p5.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"536c15cf8594b_6f3bb152ecb@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-09T17:16:54Z","receivedAt":"2014-05-09T17:16:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> \n>> > I already said this multiple times, but let me be clear once more:\n>> >\n>> > MASTER HAS A REGRESSION (for all versions of Mercurial).\n>> \n>> As you said, that is not a regression, isn't it? It is an old\n>> breakage that existed even before 1.9 (was it 1.8.3 or something?)\n>\n> No. It does't happen in 1.9, it will happen in 2.0.\n>\n> That's a REGRESSION.\n\nYou earlier said in our exchange:\n\n > Wrong. The code in question was not recent, it was introdued in 1.8.3,\n > more than one year ago.\n\nand \"git blame -L870,880 contrib/remote-helpers/git-remote-hg\" does\nshow that 68d4f4f3 (remote-hg: custom method to write tags,\n2013-04-22) is the culplit that has introduced ManifestLookupError.\n\nAnd it is in since 1.8.3. How does it break 2.0 and without\nbreaking 1.9? The dormant and otherwise unused code got its first\ncaller, or something?\n\nIf this were a core part of the system the only sensible thing we\ncan do at this point is to revert at this late stage of the cycle,\nbut I do not think I have time to bisect and find that culprit, as\ntoday is when -rc3 has been scheduled to happen.\n"},{"id":"241188","messageId":"536d179d80c86_a7adc530c7a@nysa.notmuch","threadId":"36578","inReplyTo":"xmqq61le27p5.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-09T17:59:57Z","receivedAt":"2014-05-09T17:59:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >> \n> >> > I already said this multiple times, but let me be clear once more:\n> >> >\n> >> > MASTER HAS A REGRESSION (for all versions of Mercurial).\n> >> \n> >> As you said, that is not a regression, isn't it? It is an old\n> >> breakage that existed even before 1.9 (was it 1.8.3 or something?)\n> >\n> > No. It does't happen in 1.9, it will happen in 2.0.\n> >\n> > That's a REGRESSION.\n> \n> You earlier said in our exchange:\n> \n> > Wrong. The code in question was not recent, it was introdued in 1.8.3,\n> > more than one year ago.\n> \n> and \"git blame -L870,880 contrib/remote-helpers/git-remote-hg\" does\n> show that 68d4f4f3 (remote-hg: custom method to write tags,\n> 2013-04-22) is the culplit that has introduced ManifestLookupError.\n\nThat is not a regression. It's not the issue I'm talking about.\n\n> And it is in since 1.8.3.\n\nThat is a coincidence.\n\n> How does it break 2.0 and without breaking 1.9?\n\nI said it breaks ALL VERSIONS. You are looking at two issues that are\nunrelated to the one I'm talking about.\n\n> If this were a core part of the system the only sensible thing we\n> can do at this point is to revert at this late stage of the cycle,\n> but I do not think I have time to bisect and find that culprit, as\n> today is when -rc3 has been scheduled to happen.\n\nYou won't be able to find the breakage.\n\nGood luck with your tree.\n\n-- \nFelipe Contreras\n"},{"id":"241267","messageId":"CAGK7Mr4DYuU34Zf_3fRQFkT+1TGOkpfLPUnQh=tYh6EMtBEt9A@mail.gmail.com","threadId":"36578","inReplyTo":"536ad9601b73b_3caaa612ecdc@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-11T19:33:51Z","receivedAt":"2014-05-11T19:33:51Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> I addressed every issue reported constructively, every bug report was\n> fixed, every patch reviewed and usually improved by me. I made sure\n> users of older versions wouldn't be affected negatively when the marks\n> file was upgraded, and I even setup automatic tests for different\n> versions Bazaar and Mercurial that run every time I push to my\n> repository.\n>\n> It is *way* beyond the quality of any other tool in 'contrib/' and even\n> some tools in the core, like 'git-request-pull' (which has known bugs),\n> and probably even 'git-pt'.\n\nJunio, can you comment on this? I understand this probably doesn't\nreally affect the issue at hand, but it'd help clarify if it's ever\npossible to move out of contrib/ nowadays.\n\n\n> If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If\n> git-remote-hg belongs in the contrib area, so does git-svn, and git-p4.\n\nHere too, can you clarify a bit about what should be out of tree and\nwhat should be in contrib? I understand that not all rules are set in\nstone and that there is an historical baggage for which applying all\nrules is probably more trouble than it's worth, but again it's nice to\nclarify for future users. Also it'd probably be worth commenting on\nunwritten rules about human factors (easyness of communication,\nresponse to criticisim, ability to make concessions, etc).\n\nPhilippe\n"},{"id":"241288","messageId":"CAGK7Mr7wMAaoL1EvNoJM-vA00Q0XSHY-rk3d7Srt9N4CWDj_cg@mail.gmail.com","threadId":"36578","inReplyTo":"CAGK7Mr4DYuU34Zf_3fRQFkT+1TGOkpfLPUnQh=tYh6EMtBEt9A@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-12T12:19:14Z","receivedAt":"2014-05-12T12:19:14Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"Nevermind, it'd be more efficient to cover this in the other main\nthread started by Felipe. You can answer my questions there instead as\nit'll likely benefit a wider audience.\n\nPhilippe\n"},{"id":"241312","messageId":"xmqq8uq6rd30.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"CAGK7Mr4DYuU34Zf_3fRQFkT+1TGOkpfLPUnQh=tYh6EMtBEt9A@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-12T19:50:27Z","receivedAt":"2014-05-12T19:50:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Vaucher writes:\n\n>> It is *way* beyond the quality of any other tool in 'contrib/' and even\n>> some tools in the core, like 'git-request-pull' (which has known bugs),\n>> and probably even 'git-pt'.\n>\n> Junio, can you comment on this? I understand this probably doesn't\n> really affect the issue at hand, but it'd help clarify if it's ever\n> possible to move out of contrib/ nowadays.\n\nI was originally led to believe that its code quality was good\nenough, and that was why I merged the bottom three patches of the\nseries even down to 'next' in the first place. But after seeing the\n\"Of course\" response that led to [*1*], which made me recall many\npatch-review interactions with him, I have started to have doubts.\n\nThe code quality of Git that many projects have come to trust their\ncode with is much more than just \"the code at each moment keeps\nworking for the users as long as the original author is around\".\nThe maintainer of a port to the platform X may lose access to the\nplatform after switching jobs, the maintainer of a bridge to the\nforeign system Y may stop needing to talk to the foreign system\nafter completing the switch to Git. Anybody can be hit by a bus,\nget sick, or simply lose interest in his past creations.\n\nBy reading \"git log contrib/remote-helpers\" and comparing it with\nthe logs for the rest of the system, you would realize that the\nformer would not lead to a quality discussion similar to the one\nthat led to [*2*], which was only possible because the change was\nadequately described to allow anybody to understand the original\nissue the change was meant to solve. The commit that made the\noriginal change made it easy to ask a critical question: \"You are\nimproving B but at the same time breaking A. Can we do better to\nhelp both A and B?\" And it allowed us to move forward without\nhaving to rob Peter to pay Paul.\n\nGranted, these contrib/ patches were applied with the understanding\nthat contrib/ stuff can be substandard, because having anything is\noften better than having nothing, and you cannot go back in time to\nupdate the history to make these commits more useful to others who\nwill come later. But I would be lying if I said that I would expect\nthat things will suddenly improve and that the codebase will be\nmaintained for the long haul in a healthy way the minute we move it\nout of contrib/ to the core. Especially after seeing [*1*], which\nis just one of the examples that illustrate that there clearly is no\nwill to explain the changes to help others who come later to help\nmaintaining the code. \"I'll take good care of the codebase\", \"I've\nspend the time to make it better\", \"Me, me, me\", is not what the\nopen source process is about.\n\n\n[References]\n\n*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341\n*2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204\n"},{"id":"241315","messageId":"53712cd889ba9_2ea6e1f2f82f@nysa.notmuch","threadId":"36578","inReplyTo":"xmqq8uq6rd30.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-12T20:19:36Z","receivedAt":"2014-05-12T20:19:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Philippe Vaucher writes:\n> \n> >> It is *way* beyond the quality of any other tool in 'contrib/' and even\n> >> some tools in the core, like 'git-request-pull' (which has known bugs),\n> >> and probably even 'git-pt'.\n> >\n> > Junio, can you comment on this? I understand this probably doesn't\n> > really affect the issue at hand, but it'd help clarify if it's ever\n> > possible to move out of contrib/ nowadays.\n> \n> I was originally led to believe that its code quality was good\n> enough, and that was why I merged the bottom three patches of the\n> series even down to 'next' in the first place. But after seeing the\n> \"Of course\" response that led to [*1*], which made me recall many\n> patch-review interactions with him, I have started to have doubts.\n\nThis is bullshit, and a wrong direction fallacy.\n\nEvent #1:\nJunio rejects the graduation\nhttp://article.gmane.org/gmane.comp.version-control.git/248263\n\nEvent #2:\nI give up improving remote helpers in git.git\nhttp://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341\n\nJunio is trying to make you believe that his decision (#1) was caused by\nsomething I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,\nit can't possibly be the cause.\n\n> But I would be lying if I said that I would expect\n> that things will suddenly improve and that the codebase will be\n> maintained for the long haul in a healthy way the minute we move it\n> out of contrib/ to the core. Especially after seeing [*1*]\n\n[1] happened *AFTER* you made that stupid decision.\n\nDon't make it look as if your decision was caused by [1], *YOU* caused\n[1].\n\nIf you want to show that the quality of the commit messages or the code\ncaused that decision, show an issue in that respect that happened\n*BEFORE* your decision.\n\nIt is very clear what is happening. Junio made a wrong decision based a\nnon-issue, then it became abudantly clear that there was no basis for\nsuch decision, this why he never clarified the reasoning behind. Then,\n*AFTER* I reacted to his decision he grabbed that opportunity to say\n\"no, look, this _new_ thing Felipe is doing is the reason\". Nice try.\n\nIf the behavior in [1] is the reason, the solution is easy; I'll revert\nback to my old behavior where I explained everything in detail, and\nupdated the commit messages if something wasn't clear.\n\nI would:\n\n 1. Make sure the regression is fixed Git v2.0\n 2. Send a clarified patch for the hg 3.0 compatibility\n 3. Look for other important patches that might be missing and provide\n all the details why they are important\n 4. Rebase and clean the rest of the patches to make sure nothing is\n missing\n\nThis is what I was going to do anyway *BEFORE* you made that decision.\nAnd this commitment to quality is what I've been doing since day one.\n*YOU* changed that by throwing away all my hard work.\n\nIf the issue was truly the behavior in [1], the outline above should get\nrid of the (fake) problem you mention.\n\nWe make a compromise, you ignore this temporary bump (that *you*\ncaused), and I go \"back\" to high quality standards (which I was already\ndoing anyway before). The graduation process continues, and *IF* another\ninstance like [1] comes (it won't), then the graduation process is\ncanceled.\n\nIgnoring temporary set-backs, finding common ground, and making an\nagreement on future behavior is in the best interest of our users. Will\nyou do it?\n\n> *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341\n\n-- \nFelipe Contreras\n"},{"id":"241316","messageId":"xmqqzjimpw7x.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"53712cd889ba9_2ea6e1f2f82f@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-12T20:40:02Z","receivedAt":"2014-05-12T20:40:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n> ...\n>> I was originally led to believe that its code quality was good\n>> enough, and that was why I merged the bottom three patches of the\n>> series even down to 'next' in the first place. But after seeing the\n>> \"Of course\" response that led to [*1*], which made me recall many\n>> patch-review interactions with him, I have started to have doubts.\n>\n> This is bullshit, and a wrong direction fallacy.\n>\n> Event #1:\n> Junio rejects the graduation\n> http://article.gmane.org/gmane.comp.version-control.git/248263\n>\n> Event #2:\n> I give up improving remote helpers in git.git\n> http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341\n>\n> Junio is trying to make you believe that his decision (#1) was caused by\n> something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,\n> it can't possibly be the cause.\n\nI think you misunderstood.\n\nI never said that I do not want it to graduate up (out is an option)\nbased on code quality. In fact, I do not think anybody discussed\nabout code quality until this morning.\n\nBut because I was asked, I thought about it, and then answered\nhonestly. I do not know what a trap you perceive is about, and I am\nnot interested in your responses.\n"},{"id":"241321","messageId":"537149765d67b_377bc653042f@nysa.notmuch","threadId":"36578","inReplyTo":"xmqqzjimpw7x.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-12T22:21:42Z","receivedAt":"2014-05-12T22:21:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> > ...\n> >> I was originally led to believe that its code quality was good\n> >> enough, and that was why I merged the bottom three patches of the\n> >> series even down to 'next' in the first place. But after seeing the\n> >> \"Of course\" response that led to [*1*], which made me recall many\n> >> patch-review interactions with him, I have started to have doubts.\n> >\n> > This is bullshit, and a wrong direction fallacy.\n> >\n> > Event #1:\n> > Junio rejects the graduation\n> > http://article.gmane.org/gmane.comp.version-control.git/248263\n> >\n> > Event #2:\n> > I give up improving remote helpers in git.git\n> > http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341\n> >\n> > Junio is trying to make you believe that his decision (#1) was caused by\n> > something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,\n> > it can't possibly be the cause.\n> \n> I think you misunderstood.\n> \n> I never said that I do not want it to graduate up (out is an option)\n> based on code quality.\n\nFair enough, that was my understanding up until today.\n\n> But because I was asked, I thought about it, and then answered\n> honestly. I do not know what a trap you perceive is about, and I am\n> not interested in your responses.\n\nPhilippe Vaucher didn't ask about quality, he asked about moving out of\ncontrib.\n\n-- \nFelipe Contreras\n"},{"id":"241486","messageId":"CAGK7Mr7AcqKnEBk1NwzJFJVSSQE9uWTE00zi+B9z6i0V5tBrEg@mail.gmail.com","threadId":"36578","inReplyTo":"xmqq8uq6rd30.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-14T09:12:12Z","receivedAt":"2014-05-14T09:12:12Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">>> It is *way* beyond the quality of any other tool in 'contrib/' and even\n>>> some tools in the core, like 'git-request-pull' (which has known bugs),\n>>> and probably even 'git-pt'.\n>>\n>> Junio, can you comment on this? I understand this probably doesn't\n>> really affect the issue at hand, but it'd help clarify if it's ever\n>> possible to move out of contrib/ nowadays.\n>\n> I was originally led to believe that its code quality was good\n> enough, and that was why I merged the bottom three patches of the\n> series even down to 'next' in the first place. But after seeing the\n> \"Of course\" response that led to [*1*], which made me recall many\n> patch-review interactions with him, I have started to have doubts.\n>\n> The code quality of Git that many projects have come to trust their\n> code with is much more than just \"the code at each moment keeps\n> working for the users as long as the original author is around\".\n> The maintainer of a port to the platform X may lose access to the\n> platform after switching jobs, the maintainer of a bridge to the\n> foreign system Y may stop needing to talk to the foreign system\n> after completing the switch to Git. Anybody can be hit by a bus,\n> get sick, or simply lose interest in his past creations.\n>\n> By reading \"git log contrib/remote-helpers\" and comparing it with\n> the logs for the rest of the system, you would realize that the\n> former would not lead to a quality discussion similar to the one\n> that led to [*2*], which was only possible because the change was\n> adequately described to allow anybody to understand the original\n> issue the change was meant to solve. The commit that made the\n> original change made it easy to ask a critical question: \"You are\n> improving B but at the same time breaking A. Can we do better to\n> help both A and B?\" And it allowed us to move forward without\n> having to rob Peter to pay Paul.\n>\n> Granted, these contrib/ patches were applied with the understanding\n> that contrib/ stuff can be substandard, because having anything is\n> often better than having nothing, and you cannot go back in time to\n> update the history to make these commits more useful to others who\n> will come later. But I would be lying if I said that I would expect\n> that things will suddenly improve and that the codebase will be\n> maintained for the long haul in a healthy way the minute we move it\n> out of contrib/ to the core. Especially after seeing [*1*], which\n> is just one of the examples that illustrate that there clearly is no\n> will to explain the changes to help others who come later to help\n> maintaining the code. \"I'll take good care of the codebase\", \"I've\n> spend the time to make it better\", \"Me, me, me\", is not what the\n> open source process is about.\n\nThanks for the explanation. I think it underlines well the A)\ntechnical issues (quality commits) and the B) social issues (ability\nto communicate in a friendly way & respond constructively), which we\ndiscovered are both *essential* for contributing to git.\n\nNeglate one or the other, and sooner or later people will refuse to\ncollaborate with you, because it's just too much \"work\" to deal with\nthe downsides.\n\nMy hope is that for future events of this nature to be detected sooner\nand dealt with more rigidly, e.g by making it clear this or that\nbehavior is not acceptable. I think part of the problem here is that\nwe let the situation install itself, by accepting B-side issues just\nbecause A-side was ok, hopeful that B-side would solve itself.\n\nPhilippe\n"},{"id":"241488","messageId":"87mweku2pt.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"CAGK7Mr7AcqKnEBk1NwzJFJVSSQE9uWTE00zi+B9z6i0V5tBrEg@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T09:30:38Z","receivedAt":"2014-05-14T09:30:38Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Philippe Vaucher writes:\n\n> Thanks for the explanation. I think it underlines well the A)\n> technical issues (quality commits) and the B) social issues (ability\n> to communicate in a friendly way & respond constructively), which we\n> discovered are both *essential* for contributing to git.\n\nI'm not entirely convinced of that: there is something akin to drop-dead\ngorgeous code: code that is so well done that it would not matter with\nregard to its maintenance whether or not its author dropped dead because\nit's both done well as well as documented in a manner where the original\nauthor could not offer significant additional help.\n\nOf course I am a major proponent of this view because of being myself\nsomewhat differently endowed in the respective classes A and B, and so\nhaving at least some sort of exchange rate between the two can, however\nlarge the conversion fees, only benefit me...\n\n-- \nDavid Kastrup\n"},{"id":"241489","messageId":"CAGK7Mr5ezbTVyq2wr7kYWjab6V1srrYwkqSGjo1GuPnkSuGWTQ@mail.gmail.com","threadId":"36578","inReplyTo":"87mweku2pt.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-14T09:36:54Z","receivedAt":"2014-05-14T09:36:54Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> Thanks for the explanation. I think it underlines well the A)\n>> technical issues (quality commits) and the B) social issues (ability\n>> to communicate in a friendly way & respond constructively), which we\n>> discovered are both *essential* for contributing to git.\n>\n> I'm not entirely convinced of that: there is something akin to drop-dead\n> gorgeous code: code that is so well done that it would not matter with\n> regard to its maintenance whether or not its author dropped dead because\n> it's both done well as well as documented in a manner where the original\n> author could not offer significant additional help.\n\nI think this only means that you can get away with B issues if A's\nquality is very very very high, which doens't happen very often. And I\ndoubt that you will be able to get away with it for long anyway, at\nsome point some mechanism will be put in place so the downsides of B\naren't visible to everyone... for example with the patches being sent\nto one person only and this person relays it to the list while\nfiltering B's issues.\n\nPhilippe\n"},{"id":"241491","messageId":"87iop8u1km.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"CAGK7Mr5ezbTVyq2wr7kYWjab6V1srrYwkqSGjo1GuPnkSuGWTQ@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T09:55:21Z","receivedAt":"2014-05-14T09:55:21Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Philippe Vaucher writes:\n\n>>> Thanks for the explanation. I think it underlines well the A)\n>>> technical issues (quality commits) and the B) social issues (ability\n>>> to communicate in a friendly way & respond constructively), which we\n>>> discovered are both *essential* for contributing to git.\n>>\n>> I'm not entirely convinced of that: there is something akin to drop-dead\n>> gorgeous code: code that is so well done that it would not matter with\n>> regard to its maintenance whether or not its author dropped dead because\n>> it's both done well as well as documented in a manner where the original\n>> author could not offer significant additional help.\n>\n> I think this only means that you can get away with B issues if A's\n> quality is very very very high, which doens't happen very often.\n\nI would not exactly say \"get away with B issues\". It's like saying you\ncan get away with looking like a sleazebag if you plan the time for a\ncomplete border search whenever traveling abroad.\n\nOf course that means that traveling into countries where \"complete\nborder search\" might entail depriving you of your civic rights and\nlocking you up for decades in a torture camp without due process is\nplainly not an option.\n\nBut if you are honest: everybody has to be prepared for that. It's just\nless likely to occur in practice.\n\nBasically you have to write in a manner \"if a seedy stranger gave me\nthat code on a street corner, I would have no problem checking it in\".\nIn practice, the shortcuts offering themselves through civil behavior\nand mutual trust get a lot more work done.\n\nBut they _are_ a vector for \"social engineering\".\n\nYou have to admit that it seems pretty unlikely by now that Felipe is\ntrying to sneak in some NSA-written code without arousing people's\nsuspicions.\n\n-- \nDavid Kastrup\n"},{"id":"241495","messageId":"CAGK7Mr4N5L+jRE0ykBHvopgGv1x4iNXAK+_94R5KhBxHHqMYmA@mail.gmail.com","threadId":"36578","inReplyTo":"87iop8u1km.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-14T12:11:37Z","receivedAt":"2014-05-14T12:11:37Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> Basically you have to write in a manner \"if a seedy stranger gave me\n> that code on a street corner, I would have no problem checking it in\".\n> In practice, the shortcuts offering themselves through civil behavior\n> and mutual trust get a lot more work done.\n\nMy point was more that it's very hard to produce high quality commits\nwithout social interaction with others explaining what you missed,\nstuffs you overlooked, etc. And there B issues quickly isolate you.\n\n\n> You have to admit that it seems pretty unlikely by now that Felipe is\n> trying to sneak in some NSA-written code without arousing people's\n> suspicions.\n\nNot sure where I implied otherwise... and the earlier metaphore about\ncountry borders doesn't make much sense to me.\n\nAnyway, I think we are speaking about different things. All I'm saying\nis that humans are social creatures and that thinking you can\ncontribute to projects ran by humans without according a high\nimportance to social behaviors (like Felipe thinks) is not possible.\nThreads like this are proof that while technical quality might be\nimportant for the short term, social behaviors is impossible to ignore\nin the long term.\n\nBoth are very important to be an appreciated contributor, or to\ncontribute at all in the long term.\n\nPhilippe\n"},{"id":"241496","messageId":"87egzwtthf.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"CAGK7Mr4N5L+jRE0ykBHvopgGv1x4iNXAK+_94R5KhBxHHqMYmA@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T12:50:04Z","receivedAt":"2014-05-14T12:50:04Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Philippe Vaucher writes:\n\n>> Basically you have to write in a manner \"if a seedy stranger gave me\n>> that code on a street corner, I would have no problem checking it\n>> in\". In practice, the shortcuts offering themselves through civil\n>> behavior and mutual trust get a lot more work done.\n>\n> My point was more that it's very hard to produce high quality commits\n> without social interaction with others explaining what you missed,\n> stuffs you overlooked, etc.\n\nYou are overgeneralizing. You are assuming that it's easier for\neverybody to interact with humans rather than the Tao of Computing.\n\n> And there B issues quickly isolate you.\n\nUnless you were isolated to start with.\n\n> Anyway, I think we are speaking about different things. All I'm saying\n> is that humans are social creatures and that thinking you can\n> contribute to projects ran by humans without according a high\n> importance to social behaviors (like Felipe thinks) is not possible.\n\nYou are assuming that \"according a high importance to social behaviors\"\nis all that it takes for anybody. Do you tell the beggar on the next\nstreet corner that \"according a high importance to earning millions\"\nwould be all that would be necessary for him to afford anything to drink\nthat he'd like?\n\n> Threads like this are proof that while technical quality might be\n> important for the short term, social behaviors is impossible to ignore\n> in the long term.\n\nNot really.\n\n> Both are very important to be an appreciated contributor, or to\n> contribute at all in the long term.\n\nThe one thing where social behavior comes in is noticing who tends to be\nrunning free software projects.\n\nThere is the mythical \"scratching one's itch\" theory, but it does not\nfit the bill. Those people who invest enough time into a project's\nprogress to make a fundamental difference tend to do it at the cost of\nnot having any worthwhile amount of time left actually _using_ the\nproduct.\n\nPeople mainly working on music software create very little music\nthemselves, people mainly working on text processing software do not\nwrite many texts themselves, people writing high-performance operating\nsystems have very little use for high-performance operating systems\nthemselves.\n\nAll of this might have started at one time as scratching their own itch,\nbut once their contributions become significant, it's almost always the\nitches of others they are scratching, and continue to scratch, feeling\nresponsible for them due to the skills they have been not as much\nblessed or cursed but entrusted with.\n\nAnd programming and social skills tend to be packaged separately. So\nnot everybody is gifted with being able to contribute _gracefully_.\n\n-- \nDavid Kastrup\n"},{"id":"241500","messageId":"CAGK7Mr6XTxpeJLSqL8PZMS8w+YCqxLrC5wX-dg4BdEaW3QAYTA@mail.gmail.com","threadId":"36578","inReplyTo":"87egzwtthf.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-14T13:13:24Z","receivedAt":"2014-05-14T13:13:24Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> My point was more that it's very hard to produce high quality commits\n>> without social interaction with others explaining what you missed,\n>> stuffs you overlooked, etc.\n>\n> You are overgeneralizing. You are assuming that it's easier for\n> everybody to interact with humans rather than the Tao of Computing.\n\nNo, what I'm saying is that most non-trivial patches go through a\nreview process involving human interactions. It is very hard to\nproduce a very good non-trivial patch without going through human\ninteractions, just because someone might ask a question about your\npatch. To be honest I'm not interested in fighting over this so let's\nagree to disagree.\n\n\n>> Anyway, I think we are speaking about different things. All I'm saying\n>> is that humans are social creatures and that thinking you can\n>> contribute to projects ran by humans without according a high\n>> importance to social behaviors (like Felipe thinks) is not possible.\n>\n> You are assuming that \"according a high importance to social behaviors\"\n> is all that it takes for anybody. Do you tell the beggar on the next\n> street corner that \"according a high importance to earning millions\"\n> would be all that would be necessary for him to afford anything to drink\n> that he'd like?\n\nI'm sorry that my words aren't clear enough for you to infer the point\nI'm trying to make. Let's try something simpler: what I was saying is\nthat bad behavior will get you into trouble when contributing (and\nthus it's important to behave nicely), where Felipe usualy says bad\nbehavior is irrelevant because only truth/quality is important.\n\n\n> And programming and social skills tend to be packaged separately. So\n> not everybody is gifted with being able to contribute _gracefully_.\n\nYes it's unfortunate. The amount of talent in our societies that is\nwasted because of communication problems is probably quite high. I\ndidn't find a way around \"being social\" in any human based community\nyet, but if you have an idea please share. The only way I can see\nworking is that for someone to act as a mediator between the grumpy\ncontributor and the community, but the role of this person is not very\npleasant. That or maybe have merges done by some kind of robot with\nsome AI about patch quality, but I doubt it is technically feasible\nyet.\n\nPhilippe\n"},{"id":"241501","messageId":"87a9aktqms.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"CAGK7Mr6XTxpeJLSqL8PZMS8w+YCqxLrC5wX-dg4BdEaW3QAYTA@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T13:51:39Z","receivedAt":"2014-05-14T13:51:39Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Philippe Vaucher writes:\n\n> I'm sorry that my words aren't clear enough for you to infer the point\n> I'm trying to make. Let's try something simpler: what I was saying is\n> that bad behavior will get you into trouble when contributing (and\n> thus it's important to behave nicely), where Felipe usualy says bad\n> behavior is irrelevant because only truth/quality is important.\n\nDo you feel Felipe is in control of what you label bad behavior? Do you\nfeel you are in control over how you react to his behavior?\n\n> Yes it's unfortunate. The amount of talent in our societies that is\n> wasted because of communication problems is probably quite high. I\n> didn't find a way around \"being social\" in any human based community\n> yet, but if you have an idea please share.\n\n\"being social\" as an isolated feat is self-contradictory. The question\nis how to function in a particular social context. Stock answers apply\nto stock behaviors and are obviously most efficient to apply.\n\nYesterday my girl friend bought back a mare she had sold two years ago\nbecause its owner did not manage to get along with it. It's a\ntemperamental animal that learns and performs amazingly well for its\ncomparatively compact build. But it's highest in rank \"or else\", and so\nin the end it got locked up in its stable box most of the time in order\nto avoid injuries to other horses. Now it's back here at the riding\nschool, and there is little question that there will be some injuries\nbefore things settle down again even though most of the horses here know\nit already.\n\n> The only way I can see working is that for someone to act as a\n> mediator between the grumpy contributor and the community, but the\n> role of this person is not very pleasant. That or maybe have merges\n> done by some kind of robot with some AI about patch quality, but I\n> doubt it is technically feasible yet.\n\nWell, humans are more complex. There are no sure-fire recipes even for\nworking with horses: some of them here have their separate paddocks\nbecause things would not settle down, some of them have standard\nconflicts, there are occasional injuries. The most important \"standard\nrecipe\" is to make sure that the areas accessible to multiple horses do\nnot have dead ends small enough for one horse to be able to corner\nanother. That's not really fabulous but still pretty essential. Also\nenough room all around, obviously.\n\nNow humans are often held in conditions that are not species-appropriate\nand lead to a buildup of tension. Try finding an undisturbed spot in a\ntypical city suitable for devouring a bread roll you hunted down without\ngetting other predators eyeing your prey. Almost impossible.\n\nIt may be that distributed version control systems offer more\npossibilities for organizing cooperation in a manner leaving graceful\nescape paths when things don't work out. It's not what one want to have\nto rely on permanently but it may be worth thinking about ways to make\nconsequences from difficulties less \"inevitable\" and/or grave.\n\n-- \nDavid Kastrup\n"},{"id":"241509","messageId":"CAGK7Mr7jhpizoHuA9NDnyNPy_rr8_R0m8-hCFO3CDn2Hbh3_pQ@mail.gmail.com","threadId":"36578","inReplyTo":"87a9aktqms.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-14T16:06:15Z","receivedAt":"2014-05-14T16:06:15Z","isPatch":true,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> I'm sorry that my words aren't clear enough for you to infer the point\n>> I'm trying to make. Let's try something simpler: what I was saying is\n>> that bad behavior will get you into trouble when contributing (and\n>> thus it's important to behave nicely), where Felipe usualy says bad\n>> behavior is irrelevant because only truth/quality is important.\n>\n> Do you feel Felipe is in control of what you label bad behavior? Do you\n> feel you are in control over how you react to his behavior?\n\nI feel that Felipe cannot control this (or decided not to), and I feel\nthat I am pretty much in control of my reactions given I am able to\nnot \"give in\" to the burst of emotions that some of his behavior can\ntrigger. For the record I'm not really blaming Felipe for what he\ndoes, I'm saying a solution has to be found to prevent his behavior\nfrom harming people, and that a solution that involves everyone\nadapting to Felipe is not reasonable.\n\n\n> Yesterday my girl friend bought back a mare she had sold two years ago\n> because its owner did not manage to get along with it. It's a\n> temperamental animal that learns and performs amazingly well for its\n> comparatively compact build. But it's highest in rank \"or else\", and so\n> in the end it got locked up in its stable box most of the time in order\n> to avoid injuries to other horses. Now it's back here at the riding\n> school, and there is little question that there will be some injuries\n> before things settle down again even though most of the horses here know\n> it already.\n\nI think that is the point: behave properly or be isolated to avoid\nharming others. Wether you control your behavior or not has little to\ndo with it, it's your behavior that counts. That's how it works in\npretty much any communities I know of.\n\n\n> It may be that distributed version control systems offer more\n> possibilities for organizing cooperation in a manner leaving graceful\n> escape paths when things don't work out. It's not what one want to have\n> to rely on permanently but it may be worth thinking about ways to make\n> consequences from difficulties less \"inevitable\" and/or grave.\n\nSure, I believe my proposal of acting on bad behavior earlier would\nprevent incidents like this one, because it would defuse situations\nbefore they settle in. But that's just a proposal, I'm just an\nobserver here.\n\nPhilippe\n"},{"id":"241533","messageId":"5373cfb744982_57c3bfb300a0@nysa.notmuch","threadId":"36578","inReplyTo":"CAGK7Mr7jhpizoHuA9NDnyNPy_rr8_R0m8-hCFO3CDn2Hbh3_pQ@mail.gmail.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-14T20:19:03Z","receivedAt":"2014-05-14T20:19:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Vaucher wrote:\n> >> I'm sorry that my words aren't clear enough for you to infer the point\n> >> I'm trying to make. Let's try something simpler: what I was saying is\n> >> that bad behavior will get you into trouble when contributing (and\n> >> thus it's important to behave nicely), where Felipe usualy says bad\n> >> behavior is irrelevant because only truth/quality is important.\n> >\n> > Do you feel Felipe is in control of what you label bad behavior? Do you\n> > feel you are in control over how you react to his behavior?\n> \n> I feel that Felipe cannot control this (or decided not to),\n\nI am pretty much in control of my behavior. Those who know me personally\nknow that I *never* get angry.\n\nThe problem is that what you label as \"bad behavior\" I do not. For\nexample the atheist billboard that said \"You KNOW it's a Myth. This\nSeason, Celebrate REASON!\" caused a lot of furor, and people all over\nU.S.A. said \"you cannot say that!\", \"that's offensive!\", \"it's a war\nagainst Christmass\", \"that shouldn't be tolerated in modern\nsociety\", and so on.\n\nOf course, it should be tolerated in a modern society, and it should not\nbe offensive, those are facts. Of course people can disagree with those\nfacts (but those people are wrong).\n\nThe atheists are not engaging in bad behavior, it's just that the\nmajority constituted by religious and bend-over-backwards-liberals have\na different definition of \"bad behavior\" (a wrong definition).\n\nSo if somebody convinced me that my behavior is indeed bad, I would certainly\nchange it, but I do not think it's \"bad\". Just the same way nobody has\nconvinced many atheists that their behavior in those billboards is bad.\nAnd they can't convince them, because they would need logic, reason, and\nevidence, and the atheists have them.\n\n> > Yesterday my girl friend bought back a mare she had sold two years ago\n> > because its owner did not manage to get along with it. It's a\n> > temperamental animal that learns and performs amazingly well for its\n> > comparatively compact build. But it's highest in rank \"or else\", and so\n> > in the end it got locked up in its stable box most of the time in order\n> > to avoid injuries to other horses. Now it's back here at the riding\n> > school, and there is little question that there will be some injuries\n> > before things settle down again even though most of the horses here know\n> > it already.\n> \n> I think that is the point: behave properly or be isolated to avoid\n> harming others. Wether you control your behavior or not has little to\n> do with it, it's your behavior that counts. That's how it works in\n> pretty much any communities I know of.\n\nExcept the largest and most important communities; countries. In the\nvast majority of countries what is labeled as \"bad\" (a.k.a. illegal) has\nhad much more consideration (millenia) than in most online communities\n(barely decades). Saying something is stupid might be considered \"bad\" to\nsome people, but not all, so you can't get thrown in jail for doing\nthat, even though some peple thing it's \"harming others\". For example,\nsaying \"religion is stupid\". In order to be thrown in jail you have to\ndo something _truly_ bad, something we all agree is harming others.\n\nIn online communities facts don't matter, if the majority thinks you are\ndoing something bad (even if you are not), you get thrown to jail (or\nvirtual jail).\n\n> > It may be that distributed version control systems offer more\n> > possibilities for organizing cooperation in a manner leaving graceful\n> > escape paths when things don't work out. It's not what one want to have\n> > to rely on permanently but it may be worth thinking about ways to make\n> > consequences from difficulties less \"inevitable\" and/or grave.\n> \n> Sure, I believe my proposal of acting on bad behavior earlier would\n> prevent incidents like this one, because it would defuse situations\n> before they settle in. But that's just a proposal, I'm just an\n> observer here.\n\nWhat you label \"bad behavior\" started *because* of Junio's decision.\n\nJunio made an important (to me) decision based on a *TECHNICAL* reason\nhe never explained. My \"bad behavior\" basically consisted in pointing\nout Junio's bad behavior.\n\nIn this case I'm not very dissimilar to Edward Snowden. Snowden did\nsomethig \"bad\" in the eyes of many people, but he did it *because* of\nsomething deeper and more important. It was the government that caused\nSnowden's actions, and it is the government's bad behavior that is\nimportant. But if you look at the mass media, they don't concentrate on\nthe government's actions (that's risky), they concentrate on Snowden.\n\nThis might have changed after Snowden gained support, but at least\ninitially it was this way.\n\nYou are doing exactly the same as the mass media. Instead of looking at\nthe actions of Junio, namely his *TECHNICAL* decision which *triggered*\nmy \"bad behavior\", you look at me, the easy target, and ignore the real\nproblem.\n\nWait, wait! Before focusing on deciding whether leaking documents is\n\"bad\", and how exactly it was carried out, why don't you concentrate on\nthe real issue; the fact that the government is spying on everyone. Nah!\nthat's haaard. Let's obliterate the little guy.\n\n-- \nFelipe Contreras\n"},{"id":"241535","messageId":"87mwekrsap.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"5373cfb744982_57c3bfb300a0@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T20:58:38Z","receivedAt":"2014-05-14T20:58:38Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> Philippe Vaucher wrote:\n\n[...]\n\n>> > Do you feel Felipe is in control of what you label bad behavior? Do you\n>> > feel you are in control over how you react to his behavior?\n>> \n>> I feel that Felipe cannot control this (or decided not to),\n>\n> I am pretty much in control of my behavior. Those who know me\n> personally know that I *never* get angry.\n\nYou are missing the point. The point is not what effect your behavior\nhas on you but what it has on others. As you are unable to attribute\nfeelings to others (like you appear unable to attribute reason to them),\nyou are unable to control it.\n\nIt's like repairing clockwork when your hands are numb and have never\nbeen otherwise.\n\n\"When something does not work, apply extra force\" does not work with\nclockwork. It does not work with people, either.\n\n> The problem is that what you label as \"bad behavior\" I do not.\n\nIt does not matter what you or others want to label it. The effects are\nthere anyway.\n\n> So if somebody convinced me that my behavior is indeed bad, I would\n> certainly change it, but I do not think it's \"bad\".\n\nWhat effect your behavior has on others is not dependent on what you\nthink about it.\n\nIf you convinced yourself to be standing perfectly balanced and find\nyourself falling, there is no point in not catching yourself before\nsmashing your head open just because you _know_ you have been standing\nperfectly upright.\n\n-- \nDavid Kastrup\n"},{"id":"241587","messageId":"5373e2af9ae58_592416ad2f892@nysa.notmuch","threadId":"36578","inReplyTo":"87mwekrsap.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-14T21:39:59Z","receivedAt":"2014-05-14T21:39:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > Philippe Vaucher wrote:\n> \n> [...]\n> \n> >> > Do you feel Felipe is in control of what you label bad behavior? Do you\n> >> > feel you are in control over how you react to his behavior?\n> >> \n> >> I feel that Felipe cannot control this (or decided not to),\n> >\n> > I am pretty much in control of my behavior. Those who know me\n> > personally know that I *never* get angry.\n> \n> You are missing the point. The point is not what effect your behavior\n> has on you but what it has on others.\n\nIf me saying \"I do not believe in God\" has a negative effect on Mark,\nyour answer seems to be \"do not tell Mark the truth\". If Mark was a\nco-worker and I had no option but to interact with him, I would probably\ndo something along those lines if possible. But if Mark was a member of\nan open source project, I do have an option and I'd rather tell it like\nit is. If Mark has a problem with that, I can always avoid Mark, or just\nleave the project (say if Mark was the maintainer).\n\nIn both cases Mark is wrong. I do understand that most people would\nrather comprimise their beliefs in order to win penguing points. I'm\nnot that way.\n\nIf I can't speak my mind in an open source project where I'm\ncontributing my time *for free*, I do not want to be part of that\nproject. It's the project that's wrong, not me, and it's the project\nthat looses, not me.\n\n-- \nFelipe Contreras\n"},{"id":"241590","messageId":"87egzwrovr.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"5373e2af9ae58_592416ad2f892@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T22:12:24Z","receivedAt":"2014-05-14T22:12:24Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>> Felipe Contreras writes:\n>> \n>> > Philippe Vaucher wrote:\n>> \n>> [...]\n>> \n>> >> > Do you feel Felipe is in control of what you label bad behavior? Do you\n>> >> > feel you are in control over how you react to his behavior?\n>> >> \n>> >> I feel that Felipe cannot control this (or decided not to),\n>> >\n>> > I am pretty much in control of my behavior. Those who know me\n>> > personally know that I *never* get angry.\n>> \n>> You are missing the point. The point is not what effect your behavior\n>> has on you but what it has on others.\n>\n> If me saying \"I do not believe in God\" has a negative effect on Mark,\n> your answer seems to be \"do not tell Mark the truth\".\n\nShouting \"your God is an imaginary shithead\" every time you see Mark and\nasking everybody in the room \"Isn't it right that Mark's God is an\nimaginary shithead? Can anybody here testify having seen him?\" whenever\nanybody is there, and occasionally calling him and others on the phone\nwhen you have nothing else to do and tell him that you consider his God\nan imaginary shithead and him a gullible fool to believe otherwise...\n\nDo you really think that's the way you are going to earn people's\nrespect? By prouding yourself on having seen through Mark's purported\nstupidity and pointing it out to everybody?\n\n> But if Mark was a member of an open source project, I do have an\n> option and I'd rather tell it like it is.\n\nAnd everybody else, of course, is wrong about it. And only you are\nright. All you need to do is to be as obnoxious as you can manage, and\nyou'll win everyone over to your side.\n\nDon't kid yourself: you are doing this entire sad spectacle only to\nsatisfy your own self-righteousness, just to be able to tell yourself\n\"all those people working on Git with the exception of myself are\npitiable fools and/or bad persons letting Junio pull the wool over their\neyes\".\n\nYou've made your point. People don't agree with it. Repeating your\npoint over and over will not change that.\n\n> If Mark has a problem with that, I can always avoid Mark, or just\n> leave the project (say if Mark was the maintainer).\n>\n> In both cases Mark is wrong. I do understand that most people would\n> rather comprimise their beliefs in order to win penguing points. I'm\n> not that way.\n\nNo, you rather compromise your standing in order to win your beliefs.\nTake them. They are yours. Nobody else wants them. Even if there\nwould have been merit in them originally, after revomiting them a dozen\ntimes on people's laps they just want the stench to go away.\n\n> If I can't speak my mind in an open source project where I'm\n> contributing my time *for free*, I do not want to be part of that\n> project. It's the project that's wrong, not me, and it's the project\n> that looses, not me.\n\nWell, you are a sore winner for sure.\n\n-- \nDavid Kastrup\n"},{"id":"241625","messageId":"xmqq61l8hubw.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"87mweku2pt.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-14T22:24:51Z","receivedAt":"2014-05-14T22:24:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> Philippe Vaucher writes:\n>\n>> Thanks for the explanation. I think it underlines well the A)\n>> technical issues (quality commits) and the B) social issues (ability\n>> to communicate in a friendly way & respond constructively), which we\n>> discovered are both *essential* for contributing to git.\n>\n> I'm not entirely convinced of that: there is something akin to drop-dead\n> gorgeous code: code that is so well done that it would not matter with\n> regard to its maintenance whether or not its author dropped dead because\n> it's both done well as well as documented in a manner where the original\n> author could not offer significant additional help.\n\nI would have to say that you are living in a fantasy land. During\nthe entire life of Git, I do not think I ever saw such a code that\nis perfect from the get-go and did not require any maintenance to\nadjust to the changing time.\n"},{"id":"241629","messageId":"5373ee6be6d88_7411589304d6@nysa.notmuch","threadId":"36578","inReplyTo":"87egzwrovr.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-14T22:30:03Z","receivedAt":"2014-05-14T22:30:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Shouting \"your God is an imaginary shithead\" every time you see Mark\n\nThere's no point in discussing with an unconstructive person as you.\nI've made my point, you are just talking nonsense.\n\nEvery rational person on this list knows that if I wanted to, I could be\nmuch more offsensive and insulting.\n\n-- \nFelipe Contreras\n"},{"id":"241627","messageId":"87a9akro14.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"xmqq61l8hubw.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-14T22:30:47Z","receivedAt":"2014-05-14T22:30:47Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> David Kastrup writes:\n>\n>> Philippe Vaucher writes:\n>>\n>>> Thanks for the explanation. I think it underlines well the A)\n>>> technical issues (quality commits) and the B) social issues (ability\n>>> to communicate in a friendly way & respond constructively), which we\n>>> discovered are both *essential* for contributing to git.\n>>\n>> I'm not entirely convinced of that: there is something akin to drop-dead\n>> gorgeous code: code that is so well done that it would not matter with\n>> regard to its maintenance whether or not its author dropped dead because\n>> it's both done well as well as documented in a manner where the original\n>> author could not offer significant additional help.\n>\n> I would have to say that you are living in a fantasy land. During\n> the entire life of Git, I do not think I ever saw such a code that\n> is perfect from the get-go and did not require any maintenance to\n> adjust to the changing time.\n\nYou are attacking a straw man. \"where the original author could not\noffer significant _additional_ help\" does not at all equate \"does not\nrequire any maintenance\".\n\n-- \nDavid Kastrup\n"},{"id":"241628","messageId":"xmqq1tvwhtvm.fsf@gitster.dls.corp.google.com","threadId":"36578","inReplyTo":"87a9akro14.fsf@fencepost.gnu.org","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-14T22:34:37Z","receivedAt":"2014-05-14T22:34:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n>>> I'm not entirely convinced of that: there is something akin to drop-dead\n>>> gorgeous code: code that is so well done that it would not matter with\n>>> regard to its maintenance whether or not its author dropped dead because\n>>> it's both done well as well as documented in a manner where the original\n>>> author could not offer significant additional help.\n>>\n>> I would have to say that you are living in a fantasy land. During\n>> the entire life of Git, I do not think I ever saw such a code that\n>> is perfect from the get-go and did not require any maintenance to\n>> adjust to the changing time.\n>\n> You are attacking a straw man. \"where the original author could not\n> offer significant _additional_ help\" does not at all equate \"does not\n> require any maintenance\".\n\nAhh, I realize that I misread what you wrote. Yes, I do agree with\nyou that we have a lot of pieces of code, with log messages we can\nfind with the help of blame, that the author himself does not need\nto be present for them to be maintained properly. Making all the\ncode in Git like that may be an unattainable goal, but calling the\neffort to make that happen \"living in a fantasy land\" is utterly\nwrong. Sorry about confusion.\n"},{"id":"241645","messageId":"871tvvshmz.fsf@fencepost.gnu.org","threadId":"36578","inReplyTo":"5373ee6be6d88_7411589304d6@nysa.notmuch","subject":"Re: [PATCH 0/4] remote-hg: more improvements","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-15T06:03:32Z","receivedAt":"2014-05-15T06:03:32Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>> Shouting \"your God is an imaginary shithead\" every time you see Mark\n>\n> There's no point in discussing with an unconstructive person as you.\n\nSo go to a constructive person you call your friend and show him one of\nyour calm rational mails and ask him for his opinion. Did you do so?\nWhy not? Are you so infallible in communication that a second opinion\nfrom someone you trust would be irrelevant? Or is there nobody you\ntrust?\n\n> I've made my point, you are just talking nonsense.\n>\n> Every rational person on this list knows that if I wanted to, I could\n> be much more offsensive and insulting.\n\nIt would not appear that there any rational persons on this list apart\nfrom you. Not that it matters. I think that all the other irrational\npeople on this list are rather more interested in your potential of\nbeing less offensive and insulting. Once the cure is worse than the\nailment, namely you cause fewer work to be done on Git by your presence\nthan you can do yourself, because of you distracting others and/or\nmaking them leave, it does not matter whether it could be even worse.\n\n-- \nDavid Kastrup\n"}]}