{"thread":{"id":"36465","subject":"[PATCH v2 0/3] remote-helpers: graduate","startedAt":"2014-04-21T20:37:10Z","lastAt":"2014-04-26T01:28:22Z","messageCount":17,"participants":["Felipe Contreras","Junio C Hamano","Max Horn"],"isPatch":true,"patchVersion":2,"patchTotal":3},"messages":[{"id":"239230","messageId":"1398112633-23604-1-git-send-email-felipe.contreras@gmail.com","threadId":"36465","inReplyTo":null,"subject":"[PATCH v2 0/3] remote-helpers: graduate","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:37:10Z","receivedAt":"2014-04-21T20:37:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"There doesn't seem to be any reason to keep these remote-helpers in the contrib\narea.\n\n\nFelipe Contreras (3):\n  remote-helpers: squelch python import exceptions\n  remote-helpers: move out of contrib\n  remote-helpers: move tests out of contrib\n\n .gitignore                                                 |  2 ++\n Makefile                                                   |  2 ++\n contrib/remote-helpers/Makefile                            | 14 --------------\n contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py |  0\n contrib/remote-helpers/git-remote-hg => git-remote-hg.py   |  0\n contrib/remote-helpers/test-hg.sh => t/t5810-remote-hg.sh  |  5 ++---\n .../test-hg-bidi.sh => t/t5811-remote-hg-bidi.sh           |  5 ++---\n .../test-hg-hg-git.sh => t/t5812-remote-hg-hg-git.sh       |  7 +++----\n .../remote-helpers/test-bzr.sh => t/t5820-remote-bzr.sh    |  5 ++---\n 9 files changed, 13 insertions(+), 27 deletions(-)\n delete mode 100644 contrib/remote-helpers/Makefile\n rename contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py (100%)\n rename contrib/remote-helpers/git-remote-hg => git-remote-hg.py (100%)\n rename contrib/remote-helpers/test-hg.sh => t/t5810-remote-hg.sh (99%)\n rename contrib/remote-helpers/test-hg-bidi.sh => t/t5811-remote-hg-bidi.sh (97%)\n rename contrib/remote-helpers/test-hg-hg-git.sh => t/t5812-remote-hg-hg-git.sh (98%)\n rename contrib/remote-helpers/test-bzr.sh => t/t5820-remote-bzr.sh (98%)\n\n-- \n1.9.2+fc1.1.g5c924db\n"},{"id":"239231","messageId":"1398112633-23604-2-git-send-email-felipe.contreras@gmail.com","threadId":"36465","inReplyTo":"1398112633-23604-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v2 1/3] remote-helpers: squelch python import exceptions","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:37:11Z","receivedAt":"2014-04-21T20:37:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"When the python modules are not present we get an unwanted message:\n\n    *** prove ***\n    test-bzr.sh .. Traceback (most recent call last):\n      File \"<string>\", line 1, in <module>\n      File \"/usr/local/buildtools/current/sitecustomize/sitecu...\n        return real_import(name, globals, locals, fromlist, level)\n    ImportError: No module named bzrlib\n    test-bzr.sh .. skipped: skipping remote-bzr tests; bzr not available\n    Files=1, Tests=0,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.02 ...\n\nSquelch that output.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n contrib/remote-helpers/test-bzr.sh       | 2 +-\n contrib/remote-helpers/test-hg-bidi.sh   | 2 +-\n contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--\n contrib/remote-helpers/test-hg.sh        | 2 +-\n 4 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh\nindex a4656ce..932fe8a 100755\n--- a/contrib/remote-helpers/test-bzr.sh\n+++ b/contrib/remote-helpers/test-bzr.sh\n@@ -14,7 +14,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import bzrlib'\n+if ! python -c 'import bzrlib' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-bzr tests; bzr not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\nindex d86e147..2b5aa9d 100755\n--- a/contrib/remote-helpers/test-hg-bidi.sh\n+++ b/contrib/remote-helpers/test-hg-bidi.sh\n@@ -17,7 +17,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial'\n+if ! python -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh\nindex b23909a..456a07f 100755\n--- a/contrib/remote-helpers/test-hg-hg-git.sh\n+++ b/contrib/remote-helpers/test-hg-hg-git.sh\n@@ -17,13 +17,13 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial'\n+if ! python -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\n fi\n \n-if ! python -c 'import hggit'\n+if ! python -c 'import hggit' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; hg-git not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\nindex 7d90056..056940a 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/contrib/remote-helpers/test-hg.sh\n@@ -17,7 +17,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial'\n+if ! python -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\n-- \n1.9.2+fc1.1.g5c924db\n"},{"id":"239232","messageId":"1398112633-23604-3-git-send-email-felipe.contreras@gmail.com","threadId":"36465","inReplyTo":"1398112633-23604-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:37:12Z","receivedAt":"2014-04-21T20:37:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"The remote-helpers in contrib/remote-helpers have proved to work, be\nreliable, and stable. It's time to move them out of contrib, and be\ndistributed by default.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n .gitignore                                                 | 2 ++\n Makefile                                                   | 2 ++\n contrib/remote-helpers/test-bzr.sh                         | 2 +-\n contrib/remote-helpers/test-hg-bidi.sh                     | 2 +-\n contrib/remote-helpers/test-hg-hg-git.sh                   | 4 ++--\n contrib/remote-helpers/test-hg.sh                          | 2 +-\n contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py | 0\n contrib/remote-helpers/git-remote-hg => git-remote-hg.py   | 0\n 8 files changed, 9 insertions(+), 5 deletions(-)\n rename contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py (100%)\n rename contrib/remote-helpers/git-remote-hg => git-remote-hg.py (100%)\n\ndiff --git a/.gitignore b/.gitignore\nindex dc600f9..db5f15e 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -119,11 +119,13 @@\n /git-reflog\n /git-relink\n /git-remote\n+/git-remote-bzr\n /git-remote-http\n /git-remote-https\n /git-remote-ftp\n /git-remote-ftps\n /git-remote-fd\n+/git-remote-hg\n /git-remote-ext\n /git-remote-testgit\n /git-remote-testpy\ndiff --git a/Makefile b/Makefile\nindex 2128ce3..fda4567 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -483,6 +483,8 @@ SCRIPT_PERL += git-send-email.perl\n SCRIPT_PERL += git-svn.perl\n \n SCRIPT_PYTHON += git-p4.py\n+SCRIPT_PYTHON += git-remote-hg.py\n+SCRIPT_PYTHON += git-remote-bzr.py\n \n NO_INSTALL += git-remote-testgit\n \ndiff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh\nindex 932fe8a..a656571 100755\n--- a/contrib/remote-helpers/test-bzr.sh\n+++ b/contrib/remote-helpers/test-bzr.sh\n@@ -14,7 +14,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import bzrlib' > /dev/null 2>&1\n+if ! \"$PYTHON_PATH\" -c 'import bzrlib' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-bzr tests; bzr not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\nindex 2b5aa9d..d44ec92 100755\n--- a/contrib/remote-helpers/test-hg-bidi.sh\n+++ b/contrib/remote-helpers/test-hg-bidi.sh\n@@ -17,7 +17,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial' > /dev/null 2>&1\n+if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh\nindex 456a07f..d0d186c 100755\n--- a/contrib/remote-helpers/test-hg-hg-git.sh\n+++ b/contrib/remote-helpers/test-hg-hg-git.sh\n@@ -17,13 +17,13 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial' > /dev/null 2>&1\n+if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\n fi\n \n-if ! python -c 'import hggit' > /dev/null 2>&1\n+if ! \"$PYTHON_PATH\" -c 'import hggit' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; hg-git not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\nindex 056940a..214c548 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/contrib/remote-helpers/test-hg.sh\n@@ -17,7 +17,7 @@ then\n \ttest_done\n fi\n \n-if ! python -c 'import mercurial' > /dev/null 2>&1\n+if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n then\n \tskip_all='skipping remote-hg tests; mercurial not available'\n \ttest_done\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/git-remote-bzr.py\nsimilarity index 100%\nrename from contrib/remote-helpers/git-remote-bzr\nrename to git-remote-bzr.py\ndiff --git a/contrib/remote-helpers/git-remote-hg b/git-remote-hg.py\nsimilarity index 100%\nrename from contrib/remote-helpers/git-remote-hg\nrename to git-remote-hg.py\n-- \n1.9.2+fc1.1.g5c924db\n"},{"id":"239233","messageId":"1398112633-23604-4-git-send-email-felipe.contreras@gmail.com","threadId":"36465","inReplyTo":"1398112633-23604-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v2 3/3] remote-helpers: move tests out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:37:13Z","receivedAt":"2014-04-21T20:37:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"They should be tested by default.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n contrib/remote-helpers/Makefile                            | 14 --------------\n contrib/remote-helpers/test-hg.sh => t/t5810-remote-hg.sh  |  3 +--\n .../test-hg-bidi.sh => t/t5811-remote-hg-bidi.sh           |  3 +--\n .../test-hg-hg-git.sh => t/t5812-remote-hg-hg-git.sh       |  3 +--\n .../remote-helpers/test-bzr.sh => t/t5820-remote-bzr.sh    |  3 +--\n 5 files changed, 4 insertions(+), 22 deletions(-)\n delete mode 100644 contrib/remote-helpers/Makefile\n rename contrib/remote-helpers/test-hg.sh => t/t5810-remote-hg.sh (99%)\n rename contrib/remote-helpers/test-hg-bidi.sh => t/t5811-remote-hg-bidi.sh (98%)\n rename contrib/remote-helpers/test-hg-hg-git.sh => t/t5812-remote-hg-hg-git.sh (99%)\n rename contrib/remote-helpers/test-bzr.sh => t/t5820-remote-bzr.sh (98%)\n\ndiff --git a/contrib/remote-helpers/Makefile b/contrib/remote-helpers/Makefile\ndeleted file mode 100644\nindex 239161d..0000000\n--- a/contrib/remote-helpers/Makefile\n+++ /dev/null\n@@ -1,14 +0,0 @@\n-TESTS := $(wildcard test*.sh)\n-\n-export T := $(addprefix $(CURDIR)/,$(TESTS))\n-export MAKE := $(MAKE) -e\n-export PATH := $(CURDIR):$(PATH)\n-export TEST_LINT := test-lint-executable test-lint-shell-syntax\n-\n-test:\n-\t$(MAKE) -C ../../t $@\n-\n-$(TESTS):\n-\t$(MAKE) -C ../../t $(CURDIR)/$@\n-\n-.PHONY: $(TESTS)\ndiff --git a/contrib/remote-helpers/test-hg.sh b/t/t5810-remote-hg.sh\nsimilarity index 99%\nrename from contrib/remote-helpers/test-hg.sh\nrename to t/t5810-remote-hg.sh\nindex 214c548..594a0a1 100755\n--- a/contrib/remote-helpers/test-hg.sh\n+++ b/t/t5810-remote-hg.sh\n@@ -8,8 +8,7 @@\n \n test_description='Test remote-hg'\n \n-test -n \"$TEST_DIRECTORY\" || TEST_DIRECTORY=${0%/*}/../../t\n-. \"$TEST_DIRECTORY\"/test-lib.sh\n+. ./test-lib.sh\n \n if ! test_have_prereq PYTHON\n then\ndiff --git a/contrib/remote-helpers/test-hg-bidi.sh b/t/t5811-remote-hg-bidi.sh\nsimilarity index 98%\nrename from contrib/remote-helpers/test-hg-bidi.sh\nrename to t/t5811-remote-hg-bidi.sh\nindex d44ec92..d738ed4 100755\n--- a/contrib/remote-helpers/test-hg-bidi.sh\n+++ b/t/t5811-remote-hg-bidi.sh\n@@ -8,8 +8,7 @@\n \n test_description='Test bidirectionality of remote-hg'\n \n-test -n \"$TEST_DIRECTORY\" || TEST_DIRECTORY=${0%/*}/../../t\n-. \"$TEST_DIRECTORY\"/test-lib.sh\n+. ./test-lib.sh\n \n if ! test_have_prereq PYTHON\n then\ndiff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/t/t5812-remote-hg-hg-git.sh\nsimilarity index 99%\nrename from contrib/remote-helpers/test-hg-hg-git.sh\nrename to t/t5812-remote-hg-hg-git.sh\nindex d0d186c..50c216f 100755\n--- a/contrib/remote-helpers/test-hg-hg-git.sh\n+++ b/t/t5812-remote-hg-hg-git.sh\n@@ -8,8 +8,7 @@\n \n test_description='Test remote-hg output compared to hg-git'\n \n-test -n \"$TEST_DIRECTORY\" || TEST_DIRECTORY=${0%/*}/../../t\n-. \"$TEST_DIRECTORY\"/test-lib.sh\n+. ./test-lib.sh\n \n if ! test_have_prereq PYTHON\n then\ndiff --git a/contrib/remote-helpers/test-bzr.sh b/t/t5820-remote-bzr.sh\nsimilarity index 98%\nrename from contrib/remote-helpers/test-bzr.sh\nrename to t/t5820-remote-bzr.sh\nindex a656571..8f0719a 100755\n--- a/contrib/remote-helpers/test-bzr.sh\n+++ b/t/t5820-remote-bzr.sh\n@@ -5,8 +5,7 @@\n \n test_description='Test remote-bzr'\n \n-test -n \"$TEST_DIRECTORY\" || TEST_DIRECTORY=${0%/*}/../../t\n-. \"$TEST_DIRECTORY\"/test-lib.sh\n+. ./test-lib.sh\n \n if ! test_have_prereq PYTHON\n then\n-- \n1.9.2+fc1.1.g5c924db\n"},{"id":"239240","messageId":"xmqqppka8jiw.fsf@gitster.dls.corp.google.com","threadId":"36465","inReplyTo":"1398112633-23604-3-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-21T21:22:47Z","receivedAt":"2014-04-21T21:22:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n>  contrib/remote-helpers/test-bzr.sh                         | 2 +-\n>  contrib/remote-helpers/test-hg-bidi.sh                     | 2 +-\n>  contrib/remote-helpers/test-hg-hg-git.sh                   | 4 ++--\n>  contrib/remote-helpers/test-hg.sh                          | 2 +-\n>  contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py | 0\n>  contrib/remote-helpers/git-remote-hg => git-remote-hg.py   | 0\n>  8 files changed, 9 insertions(+), 5 deletions(-)\n>  rename contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py (100%)\n>  rename contrib/remote-helpers/git-remote-hg => git-remote-hg.py (100%)\n> ...\n> diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\n> index 2b5aa9d..d44ec92 100755\n> --- a/contrib/remote-helpers/test-hg-bidi.sh\n> +++ b/contrib/remote-helpers/test-hg-bidi.sh\n> @@ -17,7 +17,7 @@ then\n>  \ttest_done\n>  fi\n>  \n> -if ! python -c 'import mercurial' > /dev/null 2>&1\n> +if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n\nDoes this change relate to the moving of main scripts, and if so\nhow?\n\nDitto for other test-*.sh scripts in the same directory.\n\n>  then\n>  \tskip_all='skipping remote-hg tests; mercurial not available'\n>  \ttest_done\n> diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh\n> index 456a07f..d0d186c 100755\n> --- a/contrib/remote-helpers/test-hg-hg-git.sh\n> +++ b/contrib/remote-helpers/test-hg-hg-git.sh\n> @@ -17,13 +17,13 @@ then\n>  \ttest_done\n>  fi\n>  \n> -if ! python -c 'import mercurial' > /dev/null 2>&1\n> +if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n>  then\n>  \tskip_all='skipping remote-hg tests; mercurial not available'\n>  \ttest_done\n>  fi\n>  \n> -if ! python -c 'import hggit' > /dev/null 2>&1\n> +if ! \"$PYTHON_PATH\" -c 'import hggit' > /dev/null 2>&1\n>  then\n>  \tskip_all='skipping remote-hg tests; hg-git not available'\n>  \ttest_done\n> diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh\n> index 056940a..214c548 100755\n> --- a/contrib/remote-helpers/test-hg.sh\n> +++ b/contrib/remote-helpers/test-hg.sh\n> @@ -17,7 +17,7 @@ then\n>  \ttest_done\n>  fi\n>  \n> -if ! python -c 'import mercurial' > /dev/null 2>&1\n> +if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n>  then\n>  \tskip_all='skipping remote-hg tests; mercurial not available'\n>  \ttest_done\n> diff --git a/contrib/remote-helpers/git-remote-bzr b/git-remote-bzr.py\n> similarity index 100%\n> rename from contrib/remote-helpers/git-remote-bzr\n> rename to git-remote-bzr.py\n> diff --git a/contrib/remote-helpers/git-remote-hg b/git-remote-hg.py\n> similarity index 100%\n> rename from contrib/remote-helpers/git-remote-hg\n> rename to git-remote-hg.py\n"},{"id":"239245","messageId":"53558c7fbd4d4_604be1f30c30@nysa.notmuch","threadId":"36465","inReplyTo":"xmqqppka8jiw.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T21:24:15Z","receivedAt":"2014-04-21T21:24:15Z","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 <felipe.contreras@gmail.com> writes:\n> \n> >  contrib/remote-helpers/test-bzr.sh                         | 2 +-\n> >  contrib/remote-helpers/test-hg-bidi.sh                     | 2 +-\n> >  contrib/remote-helpers/test-hg-hg-git.sh                   | 4 ++--\n> >  contrib/remote-helpers/test-hg.sh                          | 2 +-\n> >  contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py | 0\n> >  contrib/remote-helpers/git-remote-hg => git-remote-hg.py   | 0\n> >  8 files changed, 9 insertions(+), 5 deletions(-)\n> >  rename contrib/remote-helpers/git-remote-bzr => git-remote-bzr.py (100%)\n> >  rename contrib/remote-helpers/git-remote-hg => git-remote-hg.py (100%)\n> > ...\n> > diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\n> > index 2b5aa9d..d44ec92 100755\n> > --- a/contrib/remote-helpers/test-hg-bidi.sh\n> > +++ b/contrib/remote-helpers/test-hg-bidi.sh\n> > @@ -17,7 +17,7 @@ then\n> >  \ttest_done\n> >  fi\n> >  \n> > -if ! python -c 'import mercurial' > /dev/null 2>&1\n> > +if ! \"$PYTHON_PATH\" -c 'import mercurial' > /dev/null 2>&1\n> \n> Does this change relate to the moving of main scripts, and if so\n> how?\n\nYes.\n\nBefore the scripts were not generated, the shebang was '/usr/bin/env python',\nthat means if the user doesn't have 'python' but 'python2' git-remote-hg would\nfail, even if the user did PYTHON_PATH=python2, therefore the test scripts\nshould fail too, and that's the reason 'python' is used in the test scripts.\n\nNow that the scripts are generated the build system would replace the shebang,\nand PYTHON_PATH will be used correctly, and we should use that in the tests.\n\nI actually implemented this script generation inside contrib/remote-helpers,\nindepedently of the move, but you didn't apply those patches.\n\n-- \nFelipe Contreras\n"},{"id":"239248","messageId":"xmqqeh0q8ilm.fsf@gitster.dls.corp.google.com","threadId":"36465","inReplyTo":"53558c7fbd4d4_604be1f30c30@nysa.notmuch","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-21T21:42:45Z","receivedAt":"2014-04-21T21:42:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n>> Does this change relate to the moving of main scripts, and if so\n>> how?\n>\n> Yes.\n>\n> Before the scripts were not generated, the shebang was '/usr/bin/env python',\n> that means if the user doesn't have 'python' but 'python2' git-remote-hg would\n> fail, even if the user did PYTHON_PATH=python2, therefore the test scripts\n> should fail too, and that's the reason 'python' is used in the test scripts.\n\nAhh, OK, I agree that is a sensible change, then.  I would think\nthat deserves to be explained in the proposed log message, though.\n"},{"id":"239424","messageId":"38F8C9C6-E186-4C42-B3F0-931AE73400FA@quendi.de","threadId":"36465","inReplyTo":"1398112633-23604-3-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2014-04-23T13:10:05Z","receivedAt":"2014-04-23T13:10:05Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> The remote-helpers in contrib/remote-helpers have proved to work, be\n> reliable, and stable. It's time to move them out of contrib, and be\n> distributed by default.\n\nReally? While I agree that git-remote-hg by now works quite well for basic usage in simple situation, there are still unresolved bugs and fundamental issues with it.\n\nE.g. I recently showed you a reproducible use case involving git-remote-hg that puts the helper into a broken state from which it is difficult for a normal user to recover. Namely when a hg branch has multiple heads, then git-remote-hg exports all of those to git, but only adds a git ref for one of them; after pruning unreferenced commits, the fast-import marks file references git commits that now are missing, prompting git fast-import to crash and trash the marks file. Afterwards, attempts to push or pull from the remote hg repository are answered with an error.\n\nThere are other ways to trigger variants of this, and these are not artificial, they occur in real life (this is how I run into the issue). There are more issues related to unresolved clashes between the git and hg ways of naming things. E.g. I am collaborating on a hg repository that has branches \"foo\" and \"foo/bar\" which git-remote-hg cannot handle because it translates them to git branch names, and, well, git cannot handle that.\n\nIt may be hard to deal with some of them, and admittedly I wouldn't necessarily expect that all of these are handled from the outset, i.e. \"in version 1.0\". But I think at the very least, users should be warned about these things.\n\nMore broadly speaking, there is currently no documentation at all in git.git for those remote helpers, which I find worrisome.\n\nThat said, I don't know what the criteria are for moving something out of contrib. Perhaps it is OK to move an undocumented remote-helper with known bugs out of contrib.\n\n\nCheers,\nMax\n"},{"id":"239468","messageId":"xmqqa9bbzwc0.fsf@gitster.dls.corp.google.com","threadId":"36465","inReplyTo":"38F8C9C6-E186-4C42-B3F0-931AE73400FA@quendi.de","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-23T19:20:47Z","receivedAt":"2014-04-23T19:20:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn <max@quendi.de> writes:\n\n> That said, I don't know what the criteria are for moving something out\n> of contrib.\n\nBecause we accept stuff to contrib/, with an assumption that it is\nto stay there without contaminating the main part of the system, the\nquality of stuff in contrib/ can be sub-par and it is very possible\nthat a lot of clean-ups and fixes are necessary before moving them\nout.\n\n> Perhaps it is OK to move an undocumented remote-helper\n> with known bugs out of contrib.\n\nWe should strive to apply the same criteria as new submission to the\nmain part of the system.  And inputs from people like you who have\nmore experiences than others on the list in dealing with hg-to-git\nbridging are very much welcomed to identify and document what kind\nof breakages there are, and to come up with the solution to them.\n"},{"id":"239480","messageId":"xmqq61lzztxt.fsf@gitster.dls.corp.google.com","threadId":"36465","inReplyTo":"38F8C9C6-E186-4C42-B3F0-931AE73400FA@quendi.de","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-23T20:12:30Z","receivedAt":"2014-04-23T20:12:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn <max@quendi.de> writes:\n\n[Administrivia: please wrap your lines to reasonable length like 70-75].\n\n> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com>\n> wrote:\n>\n>> The remote-helpers in contrib/remote-helpers have proved to work, be\n>> reliable, and stable. It's time to move them out of contrib, and be\n>> distributed by default.\n>\n> Really? While I agree that git-remote-hg by now works quite well for\n> basic usage in simple situation, there are still unresolved bugs and\n> fundamental issues with it.\n\nAs you mentioned later in your message, I agree that remaining bugs\nare expected in an initial release.  I found that the above phrase\nis exaggerating, but I think you are over-reacting [*1*].\n\n> E.g. I recently showed you a reproducible use case involving\n> git-remote-hg that puts the helper into a broken state from which it\n> is difficult for a normal user to recover. Namely when ...\n> ... prompting git fast-import to crash and trash the marks\n> file. Afterwards, attempts to push or pull from the remote hg\n> repository are answered with an error.\n> There are other ways to trigger variants of this,...\n\nIsn't the recent fc/transport-helper-sync-error-fix a reasonable\nworkaround for this issue?  The split-head in Hg fundamentally\ncannot be expressed as a single ref on the Git side, and the series\nattempts not to trash the marks file when the importer quits\nabnormally for whatever reason to avoid rendering the resulting\nrepository unusable for future operations, which I thought was the\nbest you could do.\n\n> It may be hard to deal with some of them, and admittedly I wouldn't\n> necessarily expect that all of these are handled from the outset,\n> i.e. \"in version 1.0\". But I think at the very least, users should be\n> warned about these things.\n>\n> More broadly speaking, there is currently no documentation at all in\n> git.git for those remote helpers, which I find worrisome.\n\nI think your points regarding certain Hg features that do not map\nwell to Git data model are good ones; it would be good to have them\nat least documented.\n\n\n[Footnote]\n\n*1* Personally I think it would have been better if it stopped at\nsomewhere around \"some people in the field are using and reporting\nsuccess, let's give it wider exposure\", without using words like\n\"proven\", \"reliable\", or \"stable\" to make it sound like some\nobjective goodness has already been achieved.  People will call the\nresult of the project's work as \"proven to be reliable and stable\"\nif it is so; the project does not have to claim and advertise its\nware by using such words---the code will prove itself given time,\nand it is better to let others use these words, not ourselves.\n"},{"id":"239491","messageId":"5358286ba756e_24448772ec82@nysa.notmuch","threadId":"36465","inReplyTo":"38F8C9C6-E186-4C42-B3F0-931AE73400FA@quendi.de","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-23T20:54:03Z","receivedAt":"2014-04-23T20:54:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Max Horn wrote:\n> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> \n> > The remote-helpers in contrib/remote-helpers have proved to work, be\n> > reliable, and stable. It's time to move them out of contrib, and be\n> > distributed by default.\n> \n> Really? While I agree that git-remote-hg by now works quite well for basic\n> usage in simple situation, there are still unresolved bugs and fundamental\n> issues with it.\n\ns/basic usage in simple situation/complex usage in the vast majority of situations/\n\n> E.g. I recently showed you a reproducible use case involving git-remote-hg\n> that puts the helper into a broken state from which it is difficult for a\n> normal user to recover. Namely when a hg branch has multiple heads, then\n> git-remote-hg exports all of those to git, but only adds a git ref for one of\n> them; after pruning unreferenced commits, the fast-import marks file\n> references git commits that now are missing, prompting git fast-import to\n> crash and trash the marks file. Afterwards, attempts to push or pull from the\n> remote hg repository are answered with an error.\n\nYes, and how often does that happen? A normal user would only see this if a\nbranch remains with multiple heads in Mercurial for more than one month or so.\n\nIn practice that's very unlikely, and proof of that is that nobody has reported\nsuch issues.\n\nEither way, I just fixed it [1].\n\n> There are more issues related to unresolved clashes between the git and hg\n> ways of naming things. E.g. I am collaborating on a hg repository that has\n> branches \"foo\" and \"foo/bar\" which git-remote-hg cannot handle because it\n> translates them to git branch names, and, well, git cannot handle that.\n\nI don't see this as a limitation of git-remote-hg, ideally Git remote-helpers\nshould have a standardized way to let users map external branch names.\n\n> It may be hard to deal with some of them, and admittedly I wouldn't\n> necessarily expect that all of these are handled from the outset, i.e. \"in\n> version 1.0\". But I think at the very least, users should be warned about\n> these things.\n> \n> More broadly speaking, there is currently no documentation at all in git.git\n> for those remote helpers, which I find worrisome.\n\nHere is the documentation:\nhttps://github.com/felipec/git/wiki/git-remote-hg\nhttps://github.com/felipec/git/wiki/git-remote-hg\n\n> That said, I don't know what the criteria are for moving something out of\n> contrib. Perhaps it is OK to move an undocumented remote-helper with known\n> bugs out of contrib.\n\nThere are no known bugs. This is the list of open bugs:\n\nhttps://github.com/felipec/git/issues\n\nNow if you want to label the limitation of Git that you can't have both 'foo'\nand 'foo/bar' as a bug of git-remote-hg, that's up to you, but it's something\nnobody had reported before, so it definitely can't be labeled as a \"known bug\".\n\n[1] https://github.com/felipec/git/commit/fbaae8caa51804a655fd6bc5727763b64e3c2e9f\n\n-- \nFelipe Contreras\n"},{"id":"239493","messageId":"535829dd861b1_24448772ece1@nysa.notmuch","threadId":"36465","inReplyTo":"xmqqa9bbzwc0.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-23T21:00:13Z","receivedAt":"2014-04-23T21:00:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Max Horn <max@quendi.de> writes:\n> \n> > Perhaps it is OK to move an undocumented remote-helper\n> > with known bugs out of contrib.\n> \n> We should strive to apply the same criteria as new submission to the\n> main part of the system.  And inputs from people like you who have\n> more experiences than others on the list in dealing with hg-to-git\n> bridging are very much welcomed to identify and document what kind\n> of breakages there are, and to come up with the solution to them.\n\nFTR. There are no \"known brakages\", at least to me. Max Horn tends to hoard\nthese issues and never report them (unless an opportunity to criticize\ngit-remote-hg comes, apparently).\n\nThe very unlikely issue that nobody has reported about hg multiple heads and gc\nI just fixed, and the issue he just reported about 'foo' and 'foo/bar' is newly\nreported, and there's no easy way to fix this. My proposal would be to have\nsome sort of branch mapping mechanism in fast-import, but hardly something that\nshould prevent the move out of contrib.\n\n-- \nFelipe Contreras\n"},{"id":"239499","messageId":"xmqq4n1jybqx.fsf@gitster.dls.corp.google.com","threadId":"36465","inReplyTo":"535829dd861b1_24448772ece1@nysa.notmuch","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-23T21:30:46Z","receivedAt":"2014-04-23T21:30:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> The very unlikely issue that nobody has reported about hg multiple heads and gc\n> I just fixed, and the issue he just reported about 'foo' and 'foo/bar' is newly\n> reported, and there's no easy way to fix this.\n\nI would not judge on likelyhood, but I would say that 'foo' vs\n'foo/bar' is something that falls into the same category as \"if you\nwant your project to be cross-platform, don't have paths Foo and foo\nboth tracked, as some people have to work on case insensitive\nsystems\".\n\nIn other words, I think it is perfectly fine as long as the users\nare made aware of these issues.  One way to deal with such a project\nmay be to allow users to map 'foo' to 'foo_' to make room for\n'foo/bar', but lack of such a feature is not grave enough to block\nit from being used---it would be unreasonable to demand the ref\nmapping to be implemented before the command is given to the end\nusers.\n"},{"id":"239505","messageId":"EFCABE07-971C-4699-9A03-C5076B3B45ED@quendi.de","threadId":"36465","inReplyTo":"5358286ba756e_24448772ec82@nysa.notmuch","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2014-04-23T22:41:48Z","receivedAt":"2014-04-23T22:41:48Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 23.04.2014, at 22:54, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> Max Horn wrote:\n>> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n>> \n>>> The remote-helpers in contrib/remote-helpers have proved to work, be\n>>> reliable, and stable. It's time to move them out of contrib, and be\n>>> distributed by default.\n>> \n>> Really? While I agree that git-remote-hg by now works quite well for basic\n>> usage in simple situation, there are still unresolved bugs and fundamental\n>> issues with it.\n> \n> s/basic usage in simple situation/complex usage in the vast majority of situations/\n\nYeah, hm, no. We can agree to disagree, I guess. It might also depend on\nwhat you call \"basic\" or \"complex\" usage...\n\nFor example, whenever I need to\n- close a branch\n- fix a branch with multiple heads\n- deal with phases\nI need to switch to hg. I am pretty sure there are more things that make\nthat necessary, but luckily they don't happen to me.\n\nWhat does work, though (and what I count as basic usage, although I'd say it\nprobably is enough for 95% of people out there) is making a clone of \"safe\"\nrepository (i.e. no \"bad\" branch names like 'foo' together with 'foo/bar'),\npush and pull with it; and if you are careful, you can even get branch\nattribution right. This is great, but in day-to-day usage, I still regularly\nneed to work with a hg clone for some tasks. But I am not really complaining\nabout that: For most of my regular \"developer\" work, I can stay in git, and\nthat makes me happy.\n\nOut of curiosity: How do you yourself use git-remote-hg in your daily work?\nMany people I encountered are happy enough with the ability to quickly\nclone a hg repository, prepare a fix / feature branch and then submit\nit back to upstream. For this, git-remote-hg *usually* is good enough.\nBut I am worried about people hitting the edge cases where it does not\nquite work -- and then people are lost. This is what concerns me -- and\nthis concern would be alleviate if there was a list of known things that\ndo not work (and perhaps cannot work, at least for now, due to fundamental\ndifferences between hg and git which need major work to bridge over).\n\nAnyway, despite my criticism, I'd like to emphasis that I am actually quite\nhappy and grateful that your git-remote-hg exists and that you continue\nimproving it and the surrounding infrastructure. I just wish you could do it\nwhile not acting like an asshole most of the time, but I'll survive that,\ntoo *shrug*.\n\n\n\n> \n>> E.g. I recently showed you a reproducible use case involving git-remote-hg\n>> that puts the helper into a broken state from which it is difficult for a\n>> normal user to recover. Namely when a hg branch has multiple heads, then\n>> git-remote-hg exports all of those to git, but only adds a git ref for one of\n>> them; after pruning unreferenced commits, the fast-import marks file\n>> references git commits that now are missing, prompting git fast-import to\n>> crash and trash the marks file. Afterwards, attempts to push or pull from the\n>> remote hg repository are answered with an error.\n> \n> Yes, and how often does that happen? A normal user would only see this if a\n> branch remains with multiple heads in Mercurial for more than one month or so.\n\nThere are projects who do exactly that, although I believe most of them use\nbookmarks, so the issue should indeed not affect those. Anyway, they do the\nwrong thing ;-). Still, if you are forced with such a repository, it's not\nvery helpful to be told that this is your own fault...\n\nBut this kind of issue also happens in any other scenario were heads are not\nmapped to a git reference. At the very least, it also happens for closed hg\nbranches. These are quite common, and I also run into that in real life.\n\n[And to reply to a claim you made in another mail: No, I am not deliberately\n\"hoarding\" issues to make you look bad. But analyzing a breakage you run into\nand then properly writing it up takes time; and when you know you will likely\nbe insulted when reporting it doesn't really help to motivate me to sit\ndown and do that...]\n\n\n> \n> In practice that's very unlikely, and proof of that is that nobody has reported\n> such issues.\n\nNo, that logic is flawed. For example, It could also mean that not many\npeople are using the tool, and of those not many bother to report issues via\nyour github bug tracker.\n\n> \n> Either way, I just fixed it [1].\n\nThat's great to hear, thanks!\n\n> \n>> There are more issues related to unresolved clashes between the git and hg\n>> ways of naming things. E.g. I am collaborating on a hg repository that has\n>> branches \"foo\" and \"foo/bar\" which git-remote-hg cannot handle because it\n>> translates them to git branch names, and, well, git cannot handle that.\n> \n> I don't see this as a limitation of git-remote-hg, ideally Git remote-helpers\n> should have a standardized way to let users map external branch names.\n\nAgreed. But in the meantime, I think users should still be warned about it.\nOr perhaps git-remote-hg could detect this and print a more helpful message\nthat tells the user what is wrong...?\n\nI did not actively know about this limitation of git and learned about it\nwhen a hg repository I cloned caused git-remote-hg to print strange messages\nI did not understand at first... ;-). For me that's OK as I am used to\ndebugging remote-helper issue by now, but \"regular\" users might not\nfare quite so well...\n\n> \n>> It may be hard to deal with some of them, and admittedly I wouldn't\n>> necessarily expect that all of these are handled from the outset, i.e. \"in\n>> version 1.0\". But I think at the very least, users should be warned about\n>> these things.\n>> \n>> More broadly speaking, there is currently no documentation at all in git.git\n>> for those remote helpers, which I find worrisome.\n> \n> Here is the documentation:\n> https://github.com/felipec/git/wiki/git-remote-hg\n> https://github.com/felipec/git/wiki/git-remote-hg\n\n[I assume you meant one of the links to be for -bzr; but your point is clear in any case].\n\nGreat! But my point was not that there is no documentation, rather that\nthere is none in the git repository. Since you already have some\ndocumentation, this should be easy enough to resolve; e.g. for starters,\nthose links could be included in the repository. Though I think that if the\nhelpers are moved out of contrib, they'd deserve a proper help page.\n\nReading through the git-remote-hg page, here are some suggestions:\n- you already warn about octopus merges -- perhaps this would be a good\n  place to also warn about e.g. \"foo\" vs \"foo/bar\", branches with multiple heads,\n  closed branches, etc...\n- you talk about \"branch/next\", shouldn't that be \"branches/next\"?\n- indeed, branches deserve some extra attention. At the beginning of my usage\n  of your git-remote-hg and of the gitifyhg fork, I run into the problem\n  that commits I pushed to hg ended up on the wrong branch. This was because\n  I added commits to one branch, say \"branches/foo\", then merged those\n  into \"branches/bar\", then did a push -- and all commits I made ended\n  up on the hg branch \"bar\". Now I know that I need to first push \"foo\",\n  then afterwards push \"foo\".\n  I am not asking for this to be \"fixed\" because it seems hard to \"fix\n  in the general case; just that users are warned about such pitfalls\n  that do occur in basic usage in real life (and I know of other users\n  who run into it, simply by the fact that I helped multiple people to\n  get git-remote-hg or gitifyhg working and they come to me with their\n  questions).\n\n\n\n> \n>> That said, I don't know what the criteria are for moving something out of\n>> contrib. Perhaps it is OK to move an undocumented remote-helper with known\n>> bugs out of contrib.\n> \n> There are no known bugs. This is the list of open bugs:\n> \n> https://github.com/felipec/git/issues\n\nAt the time of writing, I was not aware that you had fixed the bug with the\nmarks file getting trashed. I did not yet have a chance to test your fix,\nbut I trust it works, so yeah, that resolve that. Excellent, thanks.\n\nSo, for now, there are just some \"known limitations\", but that's fine, I\nguess.\n\nNote that there are more limitations than those I listed above; not because\nI want to \"hoard\" them, but because it seems rather trivial to come up with\nthose if one thinks about it for 5 minutes, so I simply assume(d?) you are\naware of most of them. Here's what I can think of right now; this still may\nnot be complete; nor do I mean to say those should hold up anything; I merely\nwant to get them out to prevent any future accusations about \"hoarding\"\nstuff)\n\n- close hg branches cannot be referenced from git, and thus not easily\n  reopened (at least not from their old tip)\n- multiple tips/heads of a hg branch cannot be referenced; only a single\n  \"random\" head (in the sense that it is not documented how it is chosen)\n  is visible\n- more name clashes, e.g. the somewhat hypothetical case of having a hg\n  branch \"foo\" and a hg bookmark \"branches/foo\"\n- renaming remotes is a bit problematic (this is IMHO a shortcoming of the\n  remote helpers interface, not of git-remote-{hg,bzr}). I.e. it\n  can result in commits being re-exported, and hence in diverging history.\n- Not sure if this is still a problem, but I was seeing some issues when\n  a hg remote pruned some commits. Of course this is a bad thing to do in\n  the first place, but sadly it sometimes happens. IIRC this resulted in a\n  truncated marks file (which, as I understand, should be fixed already),\n  but I am a bit fuzzy on the details (it was quite some time ago, and since\n  something bad and exceptional was done on the hg side, I didn't bother to\n  look closer at it.\n\n\nMax"},{"id":"239509","messageId":"53585996ae447_3c7abff31065@nysa.notmuch","threadId":"36465","inReplyTo":"EFCABE07-971C-4699-9A03-C5076B3B45ED@quendi.de","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T00:23:50Z","receivedAt":"2014-04-24T00:23:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Max Horn wrote:\n> On 23.04.2014, at 22:54, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> > Max Horn wrote:\n> >> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> >> \n> >>> The remote-helpers in contrib/remote-helpers have proved to work, be\n> >>> reliable, and stable. It's time to move them out of contrib, and be\n> >>> distributed by default.\n> >> \n> >> Really? While I agree that git-remote-hg by now works quite well for basic\n> >> usage in simple situation, there are still unresolved bugs and fundamental\n> >> issues with it.\n> > \n> > s/basic usage in simple situation/complex usage in the vast majority of situations/\n> \n> Yeah, hm, no. We can agree to disagree, I guess.\n\nRight, except one of us has evidence to back this up:\n\n* There hasn't been a single person coming to the Git mailing (or git-fc's\n  bugtracker) reporting that they haven't been able to do something. This means\n  if there's any situation where git-remote-hg doesn't work well, it hasn't\n  been reported, and therefore the reasonable thing to assume is that if there\n  are any, they are marginal at best.\n\n> It might also depend on what you call \"basic\" or \"complex\" usage...\n> \n> For example, whenever I need to\n> - close a branch\n> - fix a branch with multiple heads\n> - deal with phases\n> I need to switch to hg. I am pretty sure there are more things that make\n> that necessary, but luckily they don't happen to me.\n\nThe fact that there are complex things you can't do, doesn't mean there isn't\nany complex usage supported at all.\n\n> Out of curiosity: How do you yourself use git-remote-hg in your daily work?\n\nI don't.\n\n> But I am worried about people hitting the edge cases where it does not quite\n> work -- and then people are lost.\n\nAnd which people are those? Are they imaginary by any chance?\n\n> This is what concerns me -- and this concern would be alleviate if there was\n> a list of known things that do not work (and perhaps cannot work, at least\n> for now, due to fundamental differences between hg and git which need major\n> work to bridge over).\n\nThat list is empty at the moment, because again, nobody has come reporting\nanything they cannot do.\n\nThe things that have been reported, I've fixed.\n\n> Anyway, despite my criticism, I'd like to emphasis that I am actually quite\n> happy and grateful that your git-remote-hg exists and that you continue\n> improving it and the surrounding infrastructure. I just wish you could do it\n> while not acting like an asshole most of the time, but I'll survive that,\n> too *shrug*.\n\nI am being straight-forward, not an asshole.\n\nIf *you* have issues, why don't *you* list them? The people that have reported\nanything back about git-remote-hg/bzr, have reported success, or their issue\nwas resolved. Even better would be if *you* fixed the issues you have.\n\n> >> E.g. I recently showed you a reproducible use case involving git-remote-hg\n> >> that puts the helper into a broken state from which it is difficult for a\n> >> normal user to recover. Namely when a hg branch has multiple heads, then\n> >> git-remote-hg exports all of those to git, but only adds a git ref for one of\n> >> them; after pruning unreferenced commits, the fast-import marks file\n> >> references git commits that now are missing, prompting git fast-import to\n> >> crash and trash the marks file. Afterwards, attempts to push or pull from the\n> >> remote hg repository are answered with an error.\n> > \n> > Yes, and how often does that happen? A normal user would only see this if a\n> > branch remains with multiple heads in Mercurial for more than one month or so.\n> \n> There are projects who do exactly that, although I believe most of them use\n> bookmarks, so the issue should indeed not affect those. Anyway, they do the\n> wrong thing ;-). Still, if you are forced with such a repository, it's not\n> very helpful to be told that this is your own fault...\n\nNobody said it's their fault, what I'm saying is that those people don't exist,\nor haven't bothered to report such issues.\n \n> But this kind of issue also happens in any other scenario were heads are not\n> mapped to a git reference.\n\nAnd where is that?\n\n> At the very least, it also happens for closed hg branches. These are quite\n> common, and I also run into that in real life.\n\nIf a branch is closed, it's ignored by git-remote-hg, so that doesn't cause a\nproblem. If there's any scenario where it would be a problem, it's certain more\ncomplex than having a closed branch.\n\n> [And to reply to a claim you made in another mail: No, I am not deliberately\n> \"hoarding\" issues to make you look bad. But analyzing a breakage you run into\n> and then properly writing it up takes time; and when you know you will likely\n> be insulted when reporting it doesn't really help to motivate me to sit\n> down and do that...]\n\nShow me exactly where anybody did insult you for reporting an issue.\n\n> > In practice that's very unlikely, and proof of that is that nobody has reported\n> > such issues.\n> \n> No, that logic is flawed. For example, It could also mean that not many\n> people are using the tool, and of those not many bother to report issues via\n> your github bug tracker.\n\nYes, it could mean that as well, if that's your contention then it doesn't\nmatter either; most people are not being affected.\n\n> >> There are more issues related to unresolved clashes between the git and hg\n> >> ways of naming things. E.g. I am collaborating on a hg repository that has\n> >> branches \"foo\" and \"foo/bar\" which git-remote-hg cannot handle because it\n> >> translates them to git branch names, and, well, git cannot handle that.\n> > \n> > I don't see this as a limitation of git-remote-hg, ideally Git remote-helpers\n> > should have a standardized way to let users map external branch names.\n> \n> Agreed. But in the meantime, I think users should still be warned about it.\n> Or perhaps git-remote-hg could detect this and print a more helpful message\n> that tells the user what is wrong...?\n\nYes, the tool could do that, but that is not something that should prevent the\nmove out of contrib, so it's not relevant for $subject.\n\n> >> It may be hard to deal with some of them, and admittedly I wouldn't\n> >> necessarily expect that all of these are handled from the outset, i.e. \"in\n> >> version 1.0\". But I think at the very least, users should be warned about\n> >> these things.\n> >> \n> >> More broadly speaking, there is currently no documentation at all in git.git\n> >> for those remote helpers, which I find worrisome.\n> > \n> > Here is the documentation:\n> > https://github.com/felipec/git/wiki/git-remote-hg\n> > https://github.com/felipec/git/wiki/git-remote-hg\n> \n> [I assume you meant one of the links to be for -bzr; but your point is clear in any case].\n> \n> Great! But my point was not that there is no documentation, rather that\n> there is none in the git repository. Since you already have some\n> documentation, this should be easy enough to resolve; e.g. for starters,\n> those links could be included in the repository. Though I think that if the\n> helpers are moved out of contrib, they'd deserve a proper help page.\n\nYes, it should be trivial to copy that documentation. This is not a\nmake-or-break point against the move.\n\n> >> That said, I don't know what the criteria are for moving something out of\n> >> contrib. Perhaps it is OK to move an undocumented remote-helper with known\n> >> bugs out of contrib.\n> > \n> > There are no known bugs. This is the list of open bugs:\n> > \n> > https://github.com/felipec/git/issues\n> \n> At the time of writing, I was not aware that you had fixed the bug with the\n> marks file getting trashed. I did not yet have a chance to test your fix,\n> but I trust it works, so yeah, that resolve that. Excellent, thanks.\n> \n> So, for now, there are just some \"known limitations\", but that's fine, I\n> guess.\n> \n> Note that there are more limitations than those I listed above; not because\n> I want to \"hoard\" them, but because it seems rather trivial to come up with\n> those if one thinks about it for 5 minutes, so I simply assume(d?) you are\n> aware of most of them. Here's what I can think of right now; this still may\n> not be complete; nor do I mean to say those should hold up anything; I merely\n> want to get them out to prevent any future accusations about \"hoarding\"\n> stuff)\n> \n> - close hg branches cannot be referenced from git, and thus not easily\n>   reopened (at least not from their old tip)\n\nEasy to fix: closed-branches/$name, or only\nrefs/hg/$remote/closed-branches/$name.\n\nHardly an issue. Nobody has reported this.\n\n> - multiple tips/heads of a hg branch cannot be referenced; only a single\n>   \"random\" head (in the sense that it is not documented how it is chosen)\n>   is visible\n\nNot random, the tip of the branch.\n\nAnd who cares?\n\n> - more name clashes, e.g. the somewhat hypothetical case of having a hg\n>   branch \"foo\" and a hg bookmark \"branches/foo\"\n\nVery important (not).\n\n> - renaming remotes is a bit problematic (this is IMHO a shortcoming of the\n>   remote helpers interface, not of git-remote-{hg,bzr}). I.e. it\n>   can result in commits being re-exported, and hence in diverging history.\n\nThat's not true. That's an issue of gitifyhg, not git-remote-hg.\n\n> - Not sure if this is still a problem, but I was seeing some issues when\n>   a hg remote pruned some commits. Of course this is a bad thing to do in\n>   the first place, but sadly it sometimes happens. IIRC this resulted in a\n>   truncated marks file (which, as I understand, should be fixed already),\n>   but I am a bit fuzzy on the details (it was quite some time ago, and since\n>   something bad and exceptional was done on the hg side, I didn't bother to\n>   look closer at it.\n\nI don't see how that could be of any issue issue since the mark files have been\nupdated.\n\nI don't see how any of these should prevent the move out of contrib, so how is\nthat relevant to the $subject? Most of these are so marginal that I wouldn't\neven bother documenting them. Maybe making a list as a to-consider, or\nto-think-about-fixing-later would make sense, but with the exception of closed\nbranches and foo vs foo/bar, I don't see much point in worrying about these\nmyself. Of course patches are welcome.\n\n-- \nFelipe Contreras\n"},{"id":"239718","messageId":"480ACEB0-7629-44DF-805F-E9543E66241B@quendi.de","threadId":"36465","inReplyTo":"53585996ae447_3c7abff31065@nysa.notmuch","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2014-04-25T22:26:29Z","receivedAt":"2014-04-25T22:26:29Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"Hi,\n\nI am going to step away from this painful discussion and also this mailing\nlist, but I owed it to send one last reply with two of the problems I am\nstill seeing, simply in the hope that this will benefit some future\ngit-remote-hg users, but also to dispel any claims I was \"hoarding\" bugs to\nsomehow hurt Felipe.\n\nBeyond that, I refuse to further \"discuss\" with Felipe on anything. It leads\nnowhere, and he is so full of himself that it seems impossible to reason\nwith him. I will also refrain from countering everything he said, even\nthough I am sure he'll construe this as me admitting that he is right. I\ndon't care enough to try to keep up the flames *shrug*.  In the end,\neverybody here can interpret this in whichever way they like.\n\nAh well, OK, I can't resist one last retort to one point Felipe wrote:\n\nOn 24.04.2014, at 02:23, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> Max Horn wrote:\n[...]\n> \n>> Out of curiosity: How do you yourself use git-remote-hg in your daily work?\n> \n> I don't.\n\nSo you don't eat your own dog-food (at most you sometimes snack on it)?\nThat would explain a lot...\n\n\n\nNow to the issues: The following results are based on git \"next\" at revision\ne8486314780a4. In addition, I cobbled together fixes from Felipe's\nrepository, namely the commit [1] he claimed to have fixed the multi head\nissue I mentioned, as well as the changes from the fc/remote/fixes branch on\nhis github repository [2].\n\nIt is very well possible that this is still not the latest and greatest, and\nthat I missed some important patch that changes everything -- it's hard to\ntell given the multitude of branches in Felipe's repository. Anyway, to\navoid confusion, I put my merged version of the script into a Gist [3], so\nif I made a mistake there, it should be easy to discover.\n\nGiven that, the following script (which Felipe already knows from his\nissue tracker [4]) still causes a fast-import crash after which \"git pull\"\nfrom the remote hg repository is impossible, and the user has no idea\nhow to recover.\n\n-- 8< --\n#!/bin/sh -ex\nrm -rf hgrepo gitrepo\n\n# Create a multi-head repository\nhg init hgrepo\ncd hgrepo\necho a > a && hg add a && hg commit -m a\necho b > b && hg add b && hg commit -m b\nhg update 0\necho c > c && hg add c && hg commit -m c\ncd ..\n\n# Clone it via remote-hg\ngit clone \"hg::hgrepo\" gitrepo\n\ncd gitrepo\ngit gc --prune=now\ngit pull  # error\n-- 8< --\n\nWhich results in this:\n\nWARNING: Branch 'default' has more than one head, consider merging\nfatal: object not found: 61780798228d17af2d34fce4cfbdf35556832472\nfast-import: dumping crash report to .git/fast_import_crash_78219\nfatal: Error while running fast-import\n\nAny subsequent pulls then give something like this:\n\nWARNING: Branch 'default' has more than one head, consider merging\nfatal: mark :6 not declared\nfast-import: dumping crash report to .git/fast_import_crash_78834\nfatal: Error while running fast-import\n\n\nWhat happens here is that a hg branch with two heads is created; this\nrepository is cloned via git-remote-hg. Both heads of the hg branch are\nimported to git, but only one is referenced by a git ref. We then prune, and\nend up with a \"missing\" commit that is still referenced by the marks file.\n\nNote that the \"next\" version I used has fc/transport-helper-sync-error-fix,\nbut this did not stop \"git fast-import\" from trashing the marks file. :-(\n\n\n\nThe second script is similar but uses a closed branch to trigger essentially\nthe same issue. Background: closed branches are ignored by git-remote-hg,\nmeaning that no git ref is created for them, which can again lead to a\ncommit without a git ref but referenced by the marks file(s). However,\nreproducing the bug in this case is a bit more complicated, because the\nproblem is obscured by another bug (?): Namely, if a hg branch is closed,\nthen git-remote-hg starts ignoring it, but does not seem to remove the ref\ncreated for that branch.  So, the git user will not see that the remote\nbranch was closed (which is a bug, I'd say); on the upside, since the ref is\nstill around, no dangling commit is produced.\n\nBut we can \"work around\" this by re-opening the hg branch at a different\nposition, i.e. as child of an unrelated commit, which does *not* have the\ncommits of the original branch as parents. If we do that, git-remote-hg\nmoves the git ref to point to the new branch tip, and again we end up with a\ndangling commit (the git commit corresponding to the former hg branch tip).\n\nAgain, this is something me and also colleagues \"discovered\" in real life\nusage. So don't be fooled by the somewhat convoluted test script. This *does*\nhappen.\n\n-- 8< ---\n#!/bin/sh -ex\n\nrm -rf hgrepo gitrepo\n\n# Create a repository with two branches\nhg init hgrepo\ncd hgrepo\necho a > a && hg add a && hg commit -m a\nhg update 0\nhg branch foobar\necho b > b && hg add b && hg commit -m b\nhg update default\ncd ..\n\n# Clone it via remote-hg\ngit clone \"hg::hgrepo\" gitrepo\ncd gitrepo\ngit gc --prune=now\ngit pull\ncd ..\n\n# close the branch\ncd hgrepo\nhg update foobar\nhg commit --close-branch -m \"close branch\"\nhg update default\ncd ..\n\ncd gitrepo\ngit gc --prune=now\ngit pull\n# This pull should trigger the issue, but for some reason, the ref\n# origin/branches/foobar is still around, and so nothing happens.\ncd ..\n\ncd hgrepo\nhg update default\nhg branch -f foobar\necho c > c && hg add c && hg commit -m c\nhg update default\ncd ..\n\ncd gitrepo\ngit gc --prune=now\ngit pull\n# at this point, origin/branches/foobar is gone\ngit gc --prune=now\ngit pull      # now we get the error\n-- 8< --\n\n\nGoodbye,\nMax\n\n\n[1] https://github.com/felipec/git/commit/fbaae8caa51804a655fd6bc5727763b64e3c2e9f\n[2] https://github.com/felipec/git/commit/1bf5fc892ebaa4a07dcd71ef96f8a8f5c876cb5f\n[3] https://gist.github.com/fingolfin/11296352\n[4] https://github.com/felipec/git/issues/56#issuecomment-40305442\n\n"},{"id":"239737","messageId":"535b0bb612af5_ba2148d31061@nysa.notmuch","threadId":"36465","inReplyTo":"480ACEB0-7629-44DF-805F-E9543E66241B@quendi.de","subject":"Re: [PATCH v2 2/3] remote-helpers: move out of contrib","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-26T01:28:22Z","receivedAt":"2014-04-26T01:28:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Max Horn wrote:\n> I am going to step away from this painful discussion and also this mailing\n> list, but I owed it to send one last reply with two of the problems I am\n> still seeing, simply in the hope that this will benefit some future\n> git-remote-hg users, but also to dispel any claims I was \"hoarding\" bugs to\n> somehow hurt Felipe.\n> \n> Beyond that, I refuse to further \"discuss\" with Felipe on anything. It leads\n> nowhere, and he is so full of himself that it seems impossible to reason\n> with him. I will also refrain from countering everything he said, even\n> though I am sure he'll construe this as me admitting that he is right. I\n> don't care enough to try to keep up the flames *shrug*.  In the end,\n> everybody here can interpret this in whichever way they like.\n\nI don't construe anything as an admission that I'm right. The $subject is that\ngit-remote-hg/bzr are ready to be moved out of contrib, that's my contention\nand I don't see why would anyone think that it's not right.\n\n> Ah well, OK, I can't resist one last retort to one point Felipe wrote:\n> \n> On 24.04.2014, at 02:23, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> \n> > Max Horn wrote:\n> [...]\n> > \n> >> Out of curiosity: How do you yourself use git-remote-hg in your daily work?\n> > \n> > I don't.\n> \n> So you don't eat your own dog-food (at most you sometimes snack on it)?\n> That would explain a lot...\n\nFortunately I don't use Mercurial in my daily work, so I can't use\ngit-remote-hg on my daily work. It's not a matter of will.\n\n> Now to the issues: The following results are based on git \"next\" at revision\n> e8486314780a4. In addition, I cobbled together fixes from Felipe's\n> repository, namely the commit [1] he claimed to have fixed the multi head\n> issue I mentioned, as well as the changes from the fc/remote/fixes branch on\n> his github repository [2].\n> \n> It is very well possible that this is still not the latest and greatest, and\n> that I missed some important patch that changes everything -- it's hard to\n> tell given the multitude of branches in Felipe's repository. Anyway, to\n> avoid confusion, I put my merged version of the script into a Gist [3], so\n> if I made a mistake there, it should be easy to discover.\n> \n> Given that, the following script (which Felipe already knows from his\n> issue tracker [4]) still causes a fast-import crash after which \"git pull\"\n> from the remote hg repository is impossible, and the user has no idea\n> how to recover.\n> \n> -- 8< --\n> #!/bin/sh -ex\n> rm -rf hgrepo gitrepo\n> \n> # Create a multi-head repository\n> hg init hgrepo\n> cd hgrepo\n> echo a > a && hg add a && hg commit -m a\n> echo b > b && hg add b && hg commit -m b\n> hg update 0\n> echo c > c && hg add c && hg commit -m c\n> cd ..\n> \n> # Clone it via remote-hg\n> git clone \"hg::hgrepo\" gitrepo\n> \n> cd gitrepo\n> git gc --prune=now\n> git pull  # error\n> -- 8< --\n> \n> Which results in this:\n> \n> WARNING: Branch 'default' has more than one head, consider merging\n> fatal: object not found: 61780798228d17af2d34fce4cfbdf35556832472\n> fast-import: dumping crash report to .git/fast_import_crash_78219\n> fatal: Error while running fast-import\n> \n> Any subsequent pulls then give something like this:\n> \n> WARNING: Branch 'default' has more than one head, consider merging\n> fatal: mark :6 not declared\n> fast-import: dumping crash report to .git/fast_import_crash_78834\n> fatal: Error while running fast-import\n\nClearly you are doing something wrong, because 'next' with the git-remote-hg\nyou put in gist[1] doesn't trigger this issue. I tested.\n\n> What happens here is that a hg branch with two heads is created; this\n> repository is cloned via git-remote-hg. Both heads of the hg branch are\n> imported to git,\n\nNo, they are not. You must be using a version of git-remote-hg other than the\none you said you did.\n\n> The second script is similar but uses a closed branch to trigger essentially\n> the same issue. Background: closed branches are ignored by git-remote-hg,\n> meaning that no git ref is created for them, which can again lead to a\n> commit without a git ref but referenced by the marks file(s). However,\n> reproducing the bug in this case is a bit more complicated, because the\n> problem is obscured by another bug (?): Namely, if a hg branch is closed,\n> then git-remote-hg starts ignoring it, but does not seem to remove the ref\n> created for that branch.  So, the git user will not see that the remote\n> branch was closed (which is a bug, I'd say); on the upside, since the ref is\n> still around, no dangling commit is produced.\n> \n> But we can \"work around\" this by re-opening the hg branch at a different\n> position, i.e. as child of an unrelated commit, which does *not* have the\n> commits of the original branch as parents. If we do that, git-remote-hg\n> moves the git ref to point to the new branch tip, and again we end up with a\n> dangling commit (the git commit corresponding to the former hg branch tip).\n> \n> Again, this is something me and also colleagues \"discovered\" in real life\n> usage. So don't be fooled by the somewhat convoluted test script. This *does*\n> happen.\n> \n> -- 8< ---\n> #!/bin/sh -ex\n> \n> rm -rf hgrepo gitrepo\n> \n> # Create a repository with two branches\n> hg init hgrepo\n> cd hgrepo\n> echo a > a && hg add a && hg commit -m a\n> hg update 0\n> hg branch foobar\n> echo b > b && hg add b && hg commit -m b\n> hg update default\n> cd ..\n> \n> # Clone it via remote-hg\n> git clone \"hg::hgrepo\" gitrepo\n> cd gitrepo\n> git gc --prune=now\n> git pull\n> cd ..\n> \n> # close the branch\n> cd hgrepo\n> hg update foobar\n> hg commit --close-branch -m \"close branch\"\n> hg update default\n> cd ..\n> \n> cd gitrepo\n> git gc --prune=now\n> git pull\n> # This pull should trigger the issue, but for some reason, the ref\n> # origin/branches/foobar is still around, and so nothing happens.\n> cd ..\n> \n> cd hgrepo\n> hg update default\n> hg branch -f foobar\n> echo c > c && hg add c && hg commit -m c\n> hg update default\n> cd ..\n> \n> cd gitrepo\n> git gc --prune=now\n> git pull\n> # at this point, origin/branches/foobar is gone\n> git gc --prune=now\n> git pull      # now we get the error\n> -- 8< --\n\nFixed.\nhttp://pastie.org/9113797\n\n[1] https://gist.github.com/fingolfin/11296352\n\n-- \nFelipe Contreras\n"}]}