{"thread":{"id":"33358","subject":"[PATCH 00/13] remote-hg: general updates","startedAt":"2013-04-02T19:02:49Z","lastAt":"2013-04-07T03:32:11Z","messageCount":48,"participants":["Felipe Contreras","Junio C Hamano","John Keeping","Max Horn","Antoine Pelisse","Jed Brown","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":13},"messages":[{"id":"212938","messageId":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":null,"subject":"[PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:49Z","receivedAt":"2013-04-02T19:02:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nHere is the next round of patches for remote-hg, some which have been\ncontributed through github.\n\nFortunately it seems to be working for the most part, but there are some\nconsiderable issues while pushing branches and tags.\n\nDusty Phillips (1):\n remote-hg: add missing config variable in doc\n\nFelipe Contreras (11):\n remote-hg: trivial cleanups\n remote-hg: properly report errors on bookmark pushes\n remote-hg: make sure fake bookmarks are updated\n remote-hg: trivial test cleanups\n remote-hg: redirect buggy mercurial output\n remote-hg: split bookmark handling\n remote-hg: refactor export\n remote-hg: update remote bookmarks\n remote-hg: force remote push\n remote-hg: don't update bookmarks unnecessarily\n remote-hg: update tags globally\n\nPeter van Zetten (1):\n remote-hg: fix for files with spaces\n\n contrib/remote-helpers/git-remote-hg | 73 ++++++++++++++++++++++++--------\n contrib/remote-helpers/test-hg-bidi.sh | 6 +--\n contrib/remote-helpers/test-hg-hg-git.sh | 4 +-\n 3 files changed, 61 insertions(+), 22 deletions(-)\n\n-- \n1.8.2\n"},{"id":"212942","messageId":"1364929382-1399-2-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 01/13] remote-hg: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:50Z","receivedAt":"2013-04-02T19:02:50Z","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 | 10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 328c2dc..d0dfb1e 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -531,7 +531,6 @@ def parse_blob(parser):\n data = parser.get_data()\n blob_marks[mark] = data\n parser.next()\n- return\n \n def get_merge_files(repo, p1, p2, files):\n for e in repo[p1].files():\n@@ -542,7 +541,7 @@ def get_merge_files(repo, p1, p2, files):\n files[e] = f\n \n def parse_commit(parser):\n- global marks, blob_marks, bmarks, parsed_refs\n+ global marks, blob_marks, parsed_refs\n global mode\n \n from_mark = merge_mark = None\n@@ -647,10 +646,11 @@ def parse_commit(parser):\n rev = repo[node].rev()\n \n parsed_refs[ref] = node\n-\n marks.new_mark(rev, commit_mark)\n \n def parse_reset(parser):\n+ global parsed_refs\n+\n ref = parser[1]\n parser.next()\n # ugh\n@@ -715,11 +715,11 @@ def do_export(parser):\n continue\n print \"ok %s\" % ref\n \n- print\n-\n if peer:\n parser.repo.push(peer, force=False)\n \n+ print\n+\n def fix_path(alias, repo, orig_url):\n repo_url = util.url(repo.url())\n url = util.url(orig_url)\n-- \n1.8.2\n"},{"id":"212940","messageId":"1364929382-1399-3-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 02/13] remote-hg: add missing config variable in doc","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:51Z","receivedAt":"2013-04-02T19:02:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"From: Dusty Phillips \n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex d0dfb1e..844ec50 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -23,6 +23,10 @@ import urllib\n # If you want to switch to hg-git compatibility mode:\n # git config --global remote-hg.hg-git-compat true\n #\n+# If you are not in hg-git-compat mode and want to disable the tracking of\n+# named branches:\n+# git config --global remote-hg.track-branches false\n+#\n # git:\n # Sensible defaults for git.\n # hg bookmarks are exported as git branches, hg branches are prefixed\n-- \n1.8.2\n"},{"id":"212941","messageId":"1364929382-1399-4-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 03/13] remote-hg: properly report errors on bookmark pushes","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:52Z","receivedAt":"2013-04-02T19:02:52Z","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 | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 844ec50..19eb4db 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -710,6 +710,7 @@ def do_export(parser):\n else:\n old = ''\n if not bookmarks.pushbookmark(parser.repo, bmark, old, node):\n+ print \"error %s\" % ref\n continue\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n-- \n1.8.2\n"},{"id":"212944","messageId":"1364929382-1399-5-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 04/13] remote-hg: fix for files with spaces","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:53Z","receivedAt":"2013-04-02T19:02:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"From: Peter van Zetten \n\nSet the maximum number of splits to make when dividing the diff stat\nlines based on space characters.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 19eb4db..c6a1a47 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -578,7 +578,7 @@ def parse_commit(parser):\n mark = int(mark_ref[1:])\n f = { 'mode' : hgmode(m), 'data' : blob_marks[mark] }\n elif parser.check('D'):\n- t, path = line.split(' ')\n+ t, path = line.split(' ', 1)\n f = { 'deleted' : True }\n else:\n die('Unknown file command: %s' % line)\n@@ -625,7 +625,7 @@ def parse_commit(parser):\n i = data.find('\\n--HG--\\n')\n if i >= 0:\n tmp = data[i + len('\\n--HG--\\n'):].strip()\n- for k, v in [e.split(' : ') for e in tmp.split('\\n')]:\n+ for k, v in [e.split(' : ', 1) for e in tmp.split('\\n')]:\n if k == 'rename':\n old, new = v.split(' => ', 1)\n files[new]['rename'] = old\n-- \n1.8.2\n"},{"id":"212945","messageId":"1364929382-1399-6-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 05/13] remote-hg: make sure fake bookmarks are updated","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:54Z","receivedAt":"2013-04-02T19:02: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 | 7 +++++++\n contrib/remote-helpers/test-hg-bidi.sh | 1 +\n contrib/remote-helpers/test-hg-hg-git.sh | 1 +\n 3 files changed, 9 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex c6a1a47..b200e60 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -709,9 +709,16 @@ def do_export(parser):\n old = bmarks[bmark].hex()\n else:\n old = ''\n+\n+ if bmark == 'master' and 'master' not in parser.repo._bookmarks:\n+ # fake bookmark\n+ print \"ok %s\" % ref\n+ continue\n+\n if not bookmarks.pushbookmark(parser.repo, bmark, old, node):\n print \"error %s\" % ref\n continue\n+\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n parser.repo.tag([tag], node, None, True, None, {})\ndiff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\nindex 1d61982..fe38e49 100755\n--- a/contrib/remote-helpers/test-hg-bidi.sh\n+++ b/contrib/remote-helpers/test-hg-bidi.sh\n@@ -30,6 +30,7 @@ git_clone () {\n hg_clone () {\n \t(\n \thg init $2 &&\n+\thg -R $2 bookmark -i master &&\n \tcd $1 &&\n \tgit push -q \"hg::$PWD/../$2\" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'\n \t) &&\ndiff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh\nindex 3f253b7..e116cb0 100755\n--- a/contrib/remote-helpers/test-hg-hg-git.sh\n+++ b/contrib/remote-helpers/test-hg-hg-git.sh\n@@ -35,6 +35,7 @@ git_clone_git () {\n hg_clone_git () {\n \t(\n \thg init $2 &&\n+\thg -R $2 bookmark -i master &&\n \tcd $1 &&\n \tgit push -q \"hg::$PWD/../$2\" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'\n \t) &&\n-- \n1.8.2\n"},{"id":"212943","messageId":"1364929382-1399-7-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 06/13] remote-hg: trivial test cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:55Z","receivedAt":"2013-04-02T19:02:55Z","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/test-hg-bidi.sh | 5 ++---\n contrib/remote-helpers/test-hg-hg-git.sh | 3 +--\n 2 files changed, 3 insertions(+), 5 deletions(-)\n\ndiff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh\nindex fe38e49..a3c88f6 100755\n--- a/contrib/remote-helpers/test-hg-bidi.sh\n+++ b/contrib/remote-helpers/test-hg-bidi.sh\n@@ -22,7 +22,6 @@ fi\n \n # clone to a git repo\n git_clone () {\n-\thg -R $1 bookmark -f -r tip master &&\n \tgit clone -q \"hg::$PWD/$1\" $2\n }\n \n@@ -201,8 +200,8 @@ test_expect_success 'hg branch' '\n \thg_push hgrepo gitrepo &&\n \thg_clone gitrepo hgrepo2 &&\n \n-\t: TODO, avoid \"master\" bookmark &&\n-\t(cd hgrepo2 && hg checkout gamma) &&\n+\t: Back to the common revision &&\n+\t(cd hgrepo && hg checkout default) &&\n \n \thg_log hgrepo > expected &&\n \thg_log hgrepo2 > actual &&\ndiff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh\nindex e116cb0..73ae18d 100755\n--- a/contrib/remote-helpers/test-hg-hg-git.sh\n+++ b/contrib/remote-helpers/test-hg-hg-git.sh\n@@ -27,7 +27,6 @@ fi\n \n # clone to a git repo with git\n git_clone_git () {\n-\thg -R $1 bookmark -f -r tip master &&\n \tgit clone -q \"hg::$PWD/$1\" $2\n }\n \n@@ -48,7 +47,7 @@ git_clone_hg () {\n \t(\n \tgit init -q $2 &&\n \tcd $1 &&\n-\thg bookmark -f -r tip master &&\n+\thg bookmark -i -f -r tip master &&\n \thg -q push -r master ../$2 || true\n \t)\n }\n-- \n1.8.2\n"},{"id":"212947","messageId":"1364929382-1399-8-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:56Z","receivedAt":"2013-04-02T19:02:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"We can't use stdout for that in remote helpers.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex b200e60..874ccd4 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -271,6 +271,7 @@ def get_repo(url, alias):\n \n myui = ui.ui()\n myui.setconfig('ui', 'interactive', 'off')\n+ myui.fout = sys.stderr\n \n if hg.islocal(url):\n repo = hg.repository(myui, url)\n-- \n1.8.2\n"},{"id":"212946","messageId":"1364929382-1399-9-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 08/13] remote-hg: split bookmark handling","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:57Z","receivedAt":"2013-04-02T19:02:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Will be useful for remote bookmarks.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 38 +++++++++++++++++++++++-------------\n 1 file changed, 24 insertions(+), 14 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 874ccd4..73d79cb 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -685,6 +685,8 @@ def parse_tag(parser):\n def do_export(parser):\n global parsed_refs, bmarks, peer\n \n+ p_bmarks = []\n+\n parser.next()\n \n for line in parser.each_block('done'):\n@@ -706,20 +708,9 @@ def do_export(parser):\n pass\n elif ref.startswith('refs/heads/'):\n bmark = ref[len('refs/heads/'):]\n- if bmark in bmarks:\n- old = bmarks[bmark].hex()\n- else:\n- old = ''\n-\n- if bmark == 'master' and 'master' not in parser.repo._bookmarks:\n- # fake bookmark\n- print \"ok %s\" % ref\n- continue\n-\n- if not bookmarks.pushbookmark(parser.repo, bmark, old, node):\n- print \"error %s\" % ref\n- continue\n-\n+ p_bmarks.append((bmark, node))\n+ # handle below\n+ continue\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n parser.repo.tag([tag], node, None, True, None, {})\n@@ -731,6 +722,25 @@ def do_export(parser):\n if peer:\n parser.repo.push(peer, force=False)\n \n+ # handle bookmarks\n+ for bmark, node in p_bmarks:\n+\n+ if bmark in bmarks:\n+ old = bmarks[bmark].hex()\n+ else:\n+ old = ''\n+\n+ if bmark == 'master' and 'master' not in parser.repo._bookmarks:\n+ # fake bookmark\n+ print \"ok %s\" % ref\n+ continue\n+\n+ if not bookmarks.pushbookmark(parser.repo, bmark, old, node):\n+ print \"error %s\" % ref\n+ continue\n+\n+ print \"ok %s\" % ref\n+\n print\n \n def fix_path(alias, repo, orig_url):\n-- \n1.8.2\n"},{"id":"212953","messageId":"1364929382-1399-10-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 09/13] remote-hg: refactor export","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:58Z","receivedAt":"2013-04-02T19:02:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"No functional changes.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 20 ++++++++++++--------\n 1 file changed, 12 insertions(+), 8 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 73d79cb..11162a2 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -9,7 +9,7 @@\n # Then you can clone with:\n # git clone hg::/path/to/mercurial/repo/\n \n-from mercurial import hg, ui, bookmarks, context, util, encoding\n+from mercurial import hg, ui, bookmarks, context, util, encoding, node\n \n import re\n import sys\n@@ -60,6 +60,9 @@ def hgmode(mode):\n m = { '100755': 'x', '120000': 'l' }\n return m.get(mode, '')\n \n+def hghex(node):\n+ return hg.node.hex(node)\n+\n def get_config(config):\n cmd = ['git', 'config', '--get', config]\n process = subprocess.Popen(cmd, stdout=subprocess.PIPE)\n@@ -705,25 +708,25 @@ def do_export(parser):\n \n for ref, node in parsed_refs.iteritems():\n if ref.startswith('refs/heads/branches'):\n- pass\n+ print \"ok %s\" % ref\n elif ref.startswith('refs/heads/'):\n bmark = ref[len('refs/heads/'):]\n p_bmarks.append((bmark, node))\n- # handle below\n continue\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n parser.repo.tag([tag], node, None, True, None, {})\n+ print \"ok %s\" % ref\n else:\n # transport-helper/fast-export bugs\n continue\n- print \"ok %s\" % ref\n \n if peer:\n parser.repo.push(peer, force=False)\n \n # handle bookmarks\n for bmark, node in p_bmarks:\n+ new = hghex(node)\n \n if bmark in bmarks:\n old = bmarks[bmark].hex()\n@@ -732,10 +735,11 @@ def do_export(parser):\n \n if bmark == 'master' and 'master' not in parser.repo._bookmarks:\n # fake bookmark\n- print \"ok %s\" % ref\n- continue\n-\n- if not bookmarks.pushbookmark(parser.repo, bmark, old, node):\n+ pass\n+ elif bookmarks.pushbookmark(parser.repo, bmark, old, new):\n+ # updated locally\n+ pass\n+ else:\n print \"error %s\" % ref\n continue\n \n-- \n1.8.2\n"},{"id":"212950","messageId":"1364929382-1399-11-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 10/13] remote-hg: update remote bookmarks","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:02:59Z","receivedAt":"2013-04-02T19:02:59Z","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 | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 11162a2..160f486 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -743,6 +743,11 @@ def do_export(parser):\n print \"error %s\" % ref\n continue\n \n+ if peer:\n+ if not peer.pushkey('bookmarks', bmark, old, new):\n+ print \"error %s\" % ref\n+ continue\n+\n print \"ok %s\" % ref\n \n print\n-- \n1.8.2\n"},{"id":"212951","messageId":"1364929382-1399-12-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 11/13] remote-hg: force remote push","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:03:00Z","receivedAt":"2013-04-02T19:03:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ideally we shouldn't do this, as it's not recommended in mercurial\ndocumentation, but there's no other way to push multiple bookmarks (on\nthe same branch), which would be the behavior most similar to git.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 160f486..a1b7e44 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -722,7 +722,7 @@ def do_export(parser):\n continue\n \n if peer:\n- parser.repo.push(peer, force=False)\n+ parser.repo.push(peer, force=True)\n \n # handle bookmarks\n for bmark, node in p_bmarks:\n-- \n1.8.2\n"},{"id":"212952","messageId":"1364929382-1399-13-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 12/13] remote-hg: don't update bookmarks unnecessarily","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:03:01Z","receivedAt":"2013-04-02T19:03:01Z","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 | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex a1b7e44..3130b23 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -733,6 +733,9 @@ def do_export(parser):\n else:\n old = ''\n \n+ if old == new:\n+ continue\n+\n if bmark == 'master' and 'master' not in parser.repo._bookmarks:\n # fake bookmark\n pass\n-- \n1.8.2\n"},{"id":"212949","messageId":"1364929382-1399-14-git-send-email-felipe.contreras@gmail.com","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 13/13] remote-hg: update tags globally","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T19:03:02Z","receivedAt":"2013-04-02T19:03:02Z","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 3130b23..c9d7636 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -715,7 +715,11 @@ def do_export(parser):\n continue\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n- parser.repo.tag([tag], node, None, True, None, {})\n+ if mode == 'git':\n+ msg = 'Added tag %s for changeset %s' % (tag, hghex(node[:6]));\n+ parser.repo.tag([tag], node, msg, False, None, {})\n+ else:\n+ parser.repo.tag([tag], node, None, True, None, {})\n print \"ok %s\" % ref\n else:\n # transport-helper/fast-export bugs\n-- \n1.8.2\n"},{"id":"212977","messageId":"7vip44d7x0.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-02T19:55:23Z","receivedAt":"2013-04-02T19:55:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Here is the next round of patches for remote-hg, some which have been\n> contributed through github.\n\nThanks.\n\n> Fortunately it seems to be working for the most part, but there are some\n> considerable issues while pushing branches and tags.\n\nDo you have a plan in mind what to do about \"some considerable\nissues\"?\n\nI could push these out to 'master' and let the interested parties\nsort it out---having early access to the code everybody bases his\neffort on would help.\n\nI could queue these on 'pu' and do the same, and wait until you say\n\"now it is ready, let's go to 'next'\" (and same for 'master').\n\nOr are they meant as \"There are issues, but here is a snapshot of\nwhat I have at this moment. Hopefully others can help me update it\nby trying it out and discussing, which may lead me to post a reroll\nfor application\"?\n\nI'll queue them on 'pu' in the meantime.\n\n>\n> Dusty Phillips (1):\n> remote-hg: add missing config variable in doc\n>\n> Felipe Contreras (11):\n> remote-hg: trivial cleanups\n> remote-hg: properly report errors on bookmark pushes\n> remote-hg: make sure fake bookmarks are updated\n> remote-hg: trivial test cleanups\n> remote-hg: redirect buggy mercurial output\n> remote-hg: split bookmark handling\n> remote-hg: refactor export\n> remote-hg: update remote bookmarks\n> remote-hg: force remote push\n> remote-hg: don't update bookmarks unnecessarily\n> remote-hg: update tags globally\n>\n> Peter van Zetten (1):\n> remote-hg: fix for files with spaces\n>\n> contrib/remote-helpers/git-remote-hg | 73 ++++++++++++++++++++++++--------\n> contrib/remote-helpers/test-hg-bidi.sh | 6 +--\n> contrib/remote-helpers/test-hg-hg-git.sh | 4 +-\n> 3 files changed, 61 insertions(+), 22 deletions(-)\n"},{"id":"212979","messageId":"7vehesd7rl.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"1364929382-1399-8-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-02T19:58:38Z","receivedAt":"2013-04-02T19:58:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> We can't use stdout for that in remote helpers.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n\nYou may want to clarify \"buggy output\" a bit. Will mercurial\nforever be broken? Some versions of Hg emit [[[it is unclear for\nJunio to tell what it is to fill this blank]]] to its output that\nwe want to ignore?\n\n> contrib/remote-helpers/git-remote-hg | 1 +\n> 1 file changed, 1 insertion(+)\n>\n> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\n> index b200e60..874ccd4 100755\n> --- a/contrib/remote-helpers/git-remote-hg\n> +++ b/contrib/remote-helpers/git-remote-hg\n> @@ -271,6 +271,7 @@ def get_repo(url, alias):\n> \n> myui = ui.ui()\n> myui.setconfig('ui', 'interactive', 'off')\n> + myui.fout = sys.stderr\n> \n> if hg.islocal(url):\n> repo = hg.repository(myui, url)\n"},{"id":"212982","messageId":"20130402200948.GF2222@serenity.lan","threadId":"33358","inReplyTo":"1364929382-1399-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-02T20:09:48Z","receivedAt":"2013-04-02T20:09:48Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:\n> Here is the next round of patches for remote-hg, some which have been\n> contributed through github.\n> \n> Fortunately it seems to be working for the most part, but there are some\n> considerable issues while pushing branches and tags.\n\nHow does this compare to the current state of gitifyhg[1]? That's built\non top of this git-remote-hg script but seems to have been more actively\ndeveloped recently.\n\n[1] https://github.com/buchuki/gitifyhg\n\n> Dusty Phillips (1):\n> remote-hg: add missing config variable in doc\n> \n> Felipe Contreras (11):\n> remote-hg: trivial cleanups\n> remote-hg: properly report errors on bookmark pushes\n> remote-hg: make sure fake bookmarks are updated\n> remote-hg: trivial test cleanups\n> remote-hg: redirect buggy mercurial output\n> remote-hg: split bookmark handling\n> remote-hg: refactor export\n> remote-hg: update remote bookmarks\n> remote-hg: force remote push\n> remote-hg: don't update bookmarks unnecessarily\n> remote-hg: update tags globally\n> \n> Peter van Zetten (1):\n> remote-hg: fix for files with spaces\n> \n> contrib/remote-helpers/git-remote-hg | 73 ++++++++++++++++++++++++--------\n> contrib/remote-helpers/test-hg-bidi.sh | 6 +--\n> contrib/remote-helpers/test-hg-hg-git.sh | 4 +-\n> 3 files changed, 61 insertions(+), 22 deletions(-)\n> \n> -- \n> 1.8.2\n"},{"id":"212986","messageId":"CAMP44s1C37+drw3HhysO4aRgxUt=knAKnT+Bk0JCqLr=CL5yjQ@mail.gmail.com","threadId":"33358","inReplyTo":"7vehesd7rl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T20:22:44Z","receivedAt":"2013-04-02T20:22:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 2, 2013 at 1:58 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> We can't use stdout for that in remote helpers.\n>>\n>> Signed-off-by: Felipe Contreras \n>> ---\n>\n> You may want to clarify \"buggy output\" a bit. Will mercurial\n> forever be broken? Some versions of Hg emit [[[it is unclear for\n> Junio to tell what it is to fill this blank]]] to its output that\n> we want to ignore?\n\nThe problem is that mercurial's code is kind of hardcoded to run under\nmercurial's UI, so it throws messages around willynillingly, like:\n\nsearching for changes\nno changes found\n\nAnd they can't be turned off. Theoretically we could override\nmercurial's UI class, but I think that has the potential to create\nmore problems, it's not worth at this point in time.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"212987","messageId":"CAMP44s1kMrXBgg8tA+1-OtxHV4cqbQ3NfqpRF6AabDWR7fQvRQ@mail.gmail.com","threadId":"33358","inReplyTo":"7vip44d7x0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-02T20:27:38Z","receivedAt":"2013-04-02T20:27:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 2, 2013 at 1:55 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Here is the next round of patches for remote-hg, some which have been\n>> contributed through github.\n>\n> Thanks.\n>\n>> Fortunately it seems to be working for the most part, but there are some\n>> considerable issues while pushing branches and tags.\n>\n> Do you have a plan in mind what to do about \"some considerable\n> issues\"?\n\nYes, they should be fixed now with this series :) I'm still waiting\nfor the people that reported those issues to confirm, but in my tests\nthey do work.\n\n> I could push these out to 'master' and let the interested parties\n> sort it out---having early access to the code everybody bases his\n> effort on would help.\n>\n> I could queue these on 'pu' and do the same, and wait until you say\n> \"now it is ready, let's go to 'next'\" (and same for 'master').\n\nThat might help. However, please drop the patch \"don't update\nbookmarks unnecessarily\", I did not intend to push that one, and I\nwould like the rest of the patches to be tested before pushing that\none out.\n\n> Or are they meant as \"There are issues, but here is a snapshot of\n> what I have at this moment. Hopefully others can help me update it\n> by trying it out and discussing, which may lead me to post a reroll\n> for application\"?\n\nNah, I think these patches fix the issues, the only question is\nwhether or not they break something else.\n\n> I'll queue them on 'pu' in the meantime.\n\nThanks.\n\n-- \nFelipe Contreras\n"},{"id":"212989","messageId":"7v8v50brfn.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"CAMP44s1C37+drw3HhysO4aRgxUt=knAKnT+Bk0JCqLr=CL5yjQ@mail.gmail.com","subject":"Re: [PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-02T20:36:44Z","receivedAt":"2013-04-02T20:36:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Tue, Apr 2, 2013 at 1:58 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> We can't use stdout for that in remote helpers.\n>>>\n>>> Signed-off-by: Felipe Contreras \n>>> ---\n>>\n>> You may want to clarify \"buggy output\" a bit. Will mercurial\n>> forever be broken? Some versions of Hg emit [[[it is unclear for\n>> Junio to tell what it is to fill this blank]]] to its output that\n>> we want to ignore?\n>\n> The problem is that mercurial's code is kind of hardcoded to run under\n> mercurial's UI, so it throws messages around willynillingly, like:\n>\n> searching for changes\n> no changes found\n>\n> And they can't be turned off. Theoretically we could override\n> mercurial's UI class, but I think that has the potential to create\n> more problems, it's not worth at this point in time.\n\nOh, I totally agree with you _after_ reading that explanation.\n\nYou just shouldn't let me waste your time to explain that to me in\nthis exchange, and you could have done so by writing a clearer log\nmessage. That's all.\n\n>\n> Cheers.\n"},{"id":"212990","messageId":"7v4nfobqy8.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"CAMP44s1kMrXBgg8tA+1-OtxHV4cqbQ3NfqpRF6AabDWR7fQvRQ@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-02T20:47:11Z","receivedAt":"2013-04-02T20:47:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Tue, Apr 2, 2013 at 1:55 PM, Junio C Hamano wrote:\n>\n>>> Fortunately it seems to be working for the most part, but there are some\n>>> considerable issues while pushing branches and tags.\n>>\n>> Do you have a plan in mind what to do about \"some considerable\n>> issues\"?\n>\n> Yes, they should be fixed now with this series :) I'm still waiting\n> for the people that reported those issues to confirm, but in my tests\n> they do work.\n\nAh, I just misread the original to mean \"This fixes pushes but still\nhas (or even adds new) considerable issues that need to be worked\nout\", hence my question.\n\n>> I could queue these on 'pu' and do the same, and wait until you say\n>> \"now it is ready, let's go to 'next'\" (and same for 'master').\n>\n> That might help. However, please drop the patch \"don't update\n> bookmarks unnecessarily\", I did not intend to push that one, and I\n> would like the rest of the patches to be tested before pushing that\n> one out.\n\nOK, then let's do that.\n\nThanks.\n"},{"id":"213000","messageId":"2670C2C0-E30F-47DA-8901-899FEE11059E@quendi.de","threadId":"33358","inReplyTo":"20130402200948.GF2222@serenity.lan","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-04-02T22:23:11Z","receivedAt":"2013-04-02T22:23:11Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 02.04.2013, at 22:09, John Keeping wrote:\n\n> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:\n>> Here is the next round of patches for remote-hg, some which have been\n>> contributed through github.\n>> \n>> Fortunately it seems to be working for the most part, but there are some\n>> considerable issues while pushing branches and tags.\n> \n> How does this compare to the current state of gitifyhg[1]? That's built\n> on top of this git-remote-hg script but seems to have been more actively\n> developed recently.\n\nSeveral bugs that were fixed in gitifyhg some time ago are now fixed in this remote-hg, too.\n\nI'll try to list some of remaining differences, mostly (in my biased opinion) improvements on the gitifyhg side. Note that some of these might be outdated with felipe's recent changes, i.e. I have not yet had time to review and/or test them all. So please bear that in mind.\n\n* added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n\n* improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't...\n\n* failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone.\n\n* git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping\n\n* internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n\n* Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].\n\n* Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)\n\n* The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\nIn particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n\n* Renaming a gitifyhg remote just works [5]. Doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember). \n\n\nSadly, while working on gitifyhg, we discovered various more design problems (from our perspective, at least) in Mercurial, e.g. the fact that commits are not necessarily normalized, in the sense that \"equivalent\" commits (same author, time, changed files / code) can have different hashs, with some nasty implications for import. This is potentially problematic because without extra care, these would be mapped to the same commit on the git side.\n\nUnfortunately, we also stumbled into various problems with the git remote-helper system. We are currently using the fast-import remote-helper type, but are encountering more and more of its limitations. This affects remote-hg and gitifyhg equally, and probably other remote helpers. E.g. \"git push --dry-run\" seems to be impossible to support with such a remote-helper (but then I might be mistaken).\n\nThing is, for several of these I don't feel quite competent enough to come up with patches that I could submit here. And in my experience just reporting a perceived problem with the remote-helper API is not going to trigger a response here [6]. I guess that's why we stopped reporting them here for now, but if there is interest I could try to compile an overview.\n\n\n[1] https://github.com/buchuki/gitifyhg\n[2] https://github.com/buchuki/gitifyhg/commit/74b71f4\n[3] https://github.com/buchuki/gitifyhg/issues/66\n[4] https://travis-ci.org/buchuki/gitifyhg/builds\n[5] https://github.com/buchuki/gitifyhg/commit/68ce89bb32\n[6] http://thread.gmane.org/gmane.comp.version-control.git/214802"},{"id":"213016","messageId":"CAMP44s3DETFBhexPhEEMP1TZGNrc91266=t16H2t_+VB_4V38w@mail.gmail.com","threadId":"33358","inReplyTo":"2670C2C0-E30F-47DA-8901-899FEE11059E@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-03T01:31:29Z","receivedAt":"2013-04-03T01:31:29Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 2, 2013 at 4:23 PM, Max Horn wrote:\n>\n> On 02.04.2013, at 22:09, John Keeping wrote:\n>\n>> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:\n>>> Here is the next round of patches for remote-hg, some which have been\n>>> contributed through github.\n>>>\n>>> Fortunately it seems to be working for the most part, but there are some\n>>> considerable issues while pushing branches and tags.\n>>\n>> How does this compare to the current state of gitifyhg[1]? That's built\n>> on top of this git-remote-hg script but seems to have been more actively\n>> developed recently.\n\nI only learned about it recently, I've looked at the history and to me\nit seems rather chaotic, and a lot of the code was simply copied from\ngit-remote-hg without comment.\n\n> * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n\nI ran these test-cases with remote-hg, and the same test-cases pass. I\nonly had to do minor modifications, most of the failures came from\nsubtle differences such as different strategies to sanitize authors,\nand which branch to pick for HEAD.\n\n> * improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't...\n\nI wouldn't call it improved. In some cases the remote-hg result is\nbetter, in others gitifyhg is, but there's only a single case where\nthe author name becomes a significant problem. It's a trivial fix.\n\n> * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone.\n\nThis is not an issue in remote-hg any more since now we force the\npush. It's not nice, but there's no other way to push multiple\nbookmarks (aka git branches) to the same branch (aka commit label).\n\nI doubt these inconsistent states can happen any more, but if they do,\nthe plan in remote-hg is to simply ignore those revisions, and only\npush the ones that have git refs. I have the code for that, but I'll\nnot be pushing it to git.git for the time being.\n\n> * git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping\n\nThis is a minor feature. I've had the code for this for quite some\ntime, but for the moment I think there are higher priorities.\n\n> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n\nI doubt this makes any difference (except for more wasted space).\n\n> * Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].\n\nThis is literally a three lines fix, and it simply makes one error\nnicer. Hardly worth mentioning.\n\n> * Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)\n\nremote-hg has the same.\n\n> * The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\n> In particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n\nI've personally checked against multiple versions of Mercurial. It's\npossible that some error might slip by, but it would get quickly\nnoticed.\n\n> * Renaming a gitifyhg remote just works [5]. Doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember).\n\nYeah, now you can change the alias of the remote, but you can't change\nthe remote url. This is not really an advantage, simply an almost\nimperceptible different choice.\n\nI still don't see any good reason why a user might prefer gitifyhg,\neven more importantly, why gitifyhg developers don't contribute to\nremote-hg.\n\nAlso, unlike remote-hg, which basically passes all the tests of\ngitifyhg, gitifyhg barely passes any tests of remote-hg (three).\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213026","messageId":"CAMP44s3czwYv7CDOkJ6t7=gYEC9s1Z2ygexfZwSs5JFfzGHGvw@mail.gmail.com","threadId":"33358","inReplyTo":"CAMP44s3DETFBhexPhEEMP1TZGNrc91266=t16H2t_+VB_4V38w@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-03T09:20:30Z","receivedAt":"2013-04-03T09:20:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 2, 2013 at 7:31 PM, Felipe Contreras\n wrote:\n\n>> * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n>\n> I ran these test-cases with remote-hg, and the same test-cases pass. I\n> only had to do minor modifications, most of the failures came from\n> subtle differences such as different strategies to sanitize authors,\n> and which branch to pick for HEAD.\n\nAfter doing some modifications in remote-hg, here are the test cases\nof gitifyhg v0.8 without modifications:\n\n========================================================= test session\nstarts ==========================================================\nplatform linux2 -- Python 2.7.3 -- pytest-2.3.4\ncollected 80 items\n\ntest/test_author.py ........F\ntest/test_clone.py ......xx.........x...x..\ntest/test_notes.py ..FxF\ntest/test_pull.py ....x..xx..\ntest/test_push.py ..............x........FF...\ntest/test_special_cases.py ...\n\n===============================================================\nFAILURES ===============================================================\n/home/felipec/tmp/gitifyhg/test/helpers.py:118: assert 'totally\n' == 'totally '\n/usr/lib/python2.7/site-packages/sh.py:309: ErrorReturnCode_128:\n/home/felipec/tmp/gitifyhg/test/test_notes.py:107: assert not 'error'\nin 'searching for changes\\nno changes found\\nFrom\nhg::file:///tmp/pytest-91/test_simple_push_updates_notes_after_contentf...rror:\nrefs/notes/hg does not point to a valid object!\\nerror:\nrefs/notes/hg-origin does not point to a valid object!\\n'\n/home/felipec/tmp/gitifyhg/test/helpers.py:108: assert [u'Added tag\n...780a9c', u'a'] == ['I tagged thi...nd user', 'a']\n/home/felipec/tmp/gitifyhg/test/test_push.py:410: assert 'default' ==\n'branch_one'\n=========================================== 5 failed, 66 passed, 9\nxfailed in 75.23 seconds ============================================\n\n-- \nFelipe Contreras\n"},{"id":"213027","messageId":"CALWbr2w2jjBmO9pTrw12UGKGC94MQqg6mZynLACLT7B3eoz8VQ@mail.gmail.com","threadId":"33358","inReplyTo":"CAMP44s3DETFBhexPhEEMP1TZGNrc91266=t16H2t_+VB_4V38w@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-04-03T09:23:51Z","receivedAt":"2013-04-03T09:23:51Z","isPatch":true,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":">> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n>\n> I doubt this makes any difference (except for more wasted space).\n\nI think this is definitely wrong. If you happen to strip a changeset\nfrom the mercurial repository, and redo a completely different commit\non top of it, the new commit will never be seen on git end (because it\nwill have the same rev id and will thus be identified as identical\nfrom git point of view).\n"},{"id":"213077","messageId":"EF2F8946-4F60-4659-9215-6C21C9641AB0@quendi.de","threadId":"33358","inReplyTo":"CAMP44s3DETFBhexPhEEMP1TZGNrc91266=t16H2t_+VB_4V38w@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-04-04T00:25:10Z","receivedAt":"2013-04-04T00:25:10Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 03.04.2013, at 03:31, Felipe Contreras wrote:\n\n> On Tue, Apr 2, 2013 at 4:23 PM, Max Horn wrote:\n>> \n>> On 02.04.2013, at 22:09, John Keeping wrote:\n>> \n>>> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:\n>>>> Here is the next round of patches for remote-hg, some which have been\n>>>> contributed through github.\n>>>> \n>>>> Fortunately it seems to be working for the most part, but there are some\n>>>> considerable issues while pushing branches and tags.\n>>> \n>>> How does this compare to the current state of gitifyhg[1]? That's built\n>>> on top of this git-remote-hg script but seems to have been more actively\n>>> developed recently.\n> \n> I only learned about it recently, I've looked at the history and to me\n> it seems rather chaotic, and a lot of the code was simply copied from\n> git-remote-hg without comment.\n\ngitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here:\n http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/\n\n\n> \n>> * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n> \n> I ran these test-cases with remote-hg, and the same test-cases pass. I\n> only had to do minor modifications, most of the failures came from\n> subtle differences such as different strategies to sanitize authors,\n> and which branch to pick for HEAD.\n\nYeah, that's because what I wrote was based on the situation before your recent patch series. Glad to see that git/contrib's remote-hg is improving!\n\n\n> \n>> * improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't...\n> \n> I wouldn't call it improved. In some cases the remote-hg result is\n> better, in others gitifyhg is,\n\nI'd love to learn about cases where remote-hg's result is better in your opinion, so that I can see if the mapping in gitifyhg could be improved for those cases.\n\nThat said, this part is really quite subjective I guess. In the end, since Mercurial names can be *anything*, one can never get a \"perfect\" mapping. Luckily, for most real repositories out there, user names will be quite sane and remote-hg and gitifyhg will produce identical results. (Although some hg repos out there have some really weird stuff going on. Yuck.)\n\n> but there's only a single case where\n> the author name becomes a significant problem. It's a trivial fix.\n\nExcellent, looking forward to it then.\n\n> \n>> * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone.\n> \n> This is not an issue in remote-hg any more since now we force the\n> push. It's not nice, but there's no other way to push multiple\n> bookmarks (aka git branches) to the same branch (aka commit label).\n\nUhh, what? The push is forced? That sounds to me like a much, much bigger issue with remote-hg than anything else ever was, from my point of view. That seems tobe akin to making \"--force\" default to \"git push\", and I don't think anybody here would consider that a good idea.\n\n> I doubt these inconsistent states can happen any more, but if they do,\n\nSeriously? This is triggered quite frequently in real life. And it will very likely cause somebody to mess up a hg repository they work on. As long is this in, using remote-hg is a total no-go for me. Just consider the following scenario:\n* user A clones a hg repository into a git repository\n* user A commits some commits in the git clone\n* meanwhile, user B pushes changes to the hg repository\n* user A tries to push his changes to the hg remote\n\nThe last step causes this result in gitifyhg (similar to what one gets when the remote is a git repos):\n\n ! [rejected] master -> master (non-fast-forward)\nerror: failed to push some refs to 'gitifyhg::URL'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\nhint: before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details.\n\n\nWith remote-hg, you just force push the change, creating a new head in the remote repo. So, yeah, failed pushes which mess up the internal state don't happen anymore. But I rather have those than potentially mess up the upstream repository like that.\n\n\n> the plan in remote-hg is to simply ignore those revisions, and only\n> push the ones that have git refs. I have the code for that, but I'll\n> not be pushing it to git.git for the time being.\n\nI am not quite sure what you mean here, but I'll just wait for your code and hope it'll explain itself.\n\n> \n>> * git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping\n> \n> This is a minor feature. I've had the code for this for quite some\n> time, but for the moment I think there are higher priorities.\n\nWell, I guess it depends on how you use this. In my daily work with hg repositories, that's a quite important feature. \n\nActually, I wonder: Are you actually using remote-hg yourself for day-to-day development? Or for any other regular activities? You seem to have quite different usage patterns from me and other people involved with gitifyhg.\n\n> \n>> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n> \n> I doubt this makes any difference (except for more wasted space).\n\nI disagree. Especially since remote-hg does treat local hg repositories differently than remote ones, by not cloning them but rather working with them directly. As soon as somebody uses \"hg strip\" or \"hg graft\", etc. on that, your mark files will contain incorrect data.\n\nWith a remote hg repository, that is of course not as much of an issue, since you have a local hg clone stored inside of .git/. In theory, the user would never touch that, so nothing in there changes. In reality, though, sometimes the user still has to dig in there and modify things (e.g. to undo a \"bad\" push; although of course for now you \"fixed\" that particular problem by force pushing). Of course in an ideal world, a user never should have to do that, but as long as there are bugs, users may have to. And based on painful experience, it is *much* easier to do that when the marks use the invariant hashes instead of the transient rev ids.\n\nAs for the wasted space: For a repository with 999,999 commits, the size of the \"marks-hg file should increase from about 1.5 MB to about 5 MB. To use your words: Hardly worth mentioning.\n\n\n> \n>> * Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].\n> \n> This is literally a three lines fix, and it simply makes one error\n> nicer. Hardly worth mentioning.\n\nPerhaps not for you, but for users who just want to use remote-hg resp. gitifyhg, getting a helpful error message instead of seeing an (to them) unreadable stack trace is quite important. I guess this just shows that we have quite different goals and ideas about how to interact with users of our respective tools :-).\n\nAnyway, I hope you'll consider applying something like that three lines fix to remote-hg.\n\n> \n>> * Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)\n> \n> remote-hg has the same.\n\nExcellent.\n\n> \n>> * The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\n>> In particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n> \n> I've personally checked against multiple versions of Mercurial. It's\n> possible that some error might slip by, but it would get quickly\n> noticed.\n\nReally? This sounds close to some people who say things like \"I don't need a test suite, I personally run some tests every now and then on my machine.\"\nOf course clearly that is not at all how you operate. Rather you are very sensible and strive to provide a good testsuite which strives to test as much stuff as possible. As it should be. Which is why I am surprised that you compare (a) \"personally\" checking against some unspecified \"multiple versions of Mercurial\" at an unspecified frequency with (b) automatically running a testsuite after each push against a specific set of Mercurial versions. Versions which were specifically selected to match what Ubuntu 11.10, 12.04 LTS and 12.10 resp. Debian Wheezy provide, as well as recent versions. See also . I would like to also let this check with multiple git versions, but that requires collecting / making suitable .debs which I have n\n ot yet gotten around to.\n\nFurthermore, you don't seem to document what versions of Mercurial are supposed to work / not work. (Indeed, as far as I can tell, remote-hg has no documentation whatsoever, another difference. Granted, the gitifyhg README is not particular great at this point, but at least it exists and tells people how to get started and where to get help).\n\nIn contrast, the gitifyhg README clearly states that it \"requires at least Mercurial 1.9\". And its setup.py refuses to install it if the Mercurial version is too old. Again, for us devs that's not very important, but for users, I think it is. In recent months, I had to provide assistance with using hg to tons of people (*sigh*), and old Mercurial versions came up in a considerable portion of those (perhaps 30-40% or so). \n\n> \n>> * Renaming a gitifyhg remote just works [5]. Doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember).\n> \n> Yeah, now you can change the alias of the remote, but you can't change\n> the remote url.\n\nThat's simply wrong. You still can change the remote URL, it will just lead to the creation of a fresh separate local clone.\n\nIn contrast, with remote-hg, renaming the remote will create a fresh local clone, while changing the remote URL will *not* do that -- instead, the changes from the new remote will be pulled into the existing local clone. Which in some cases may be exactly what you want (e.g. if a repository just moved to a different remote URL). But in other cases, it won't be, namely when the repository at the new URL contains different content. This is not that unlikely when you consider that it comment Mercurial workflow to use separate repositories for different branches.\n\n\n> This is not really an advantage, simply an almost\n> imperceptible different choice.\n\nThese are indeed different design choices, but at least to me, they are very much perceptible :-). And we made this design choice quite consciously, after looking at how it is done in remote-hg, and not liking that.\n\nAnyway: At least in my day-to-day operations, I occasionally rename a remote (very rare, but it happens). So far I never had to change a remote URL. Of course that is just me, perhaps others occasionally (well, more of than me :-) have to change remote URLs. But as I said, that's still possible in gitifyhg.\n\nThat said, the situation is certainly not ideal. The fact that remote helpers have no good way to notice if the remote name (or URL, or anything) have changed is the root problem at hand here, I'd say. But for now, we are happy enough with the solution we implemented in gitifyhg, at least for our purposes.\n\n\n> I still don't see any good reason why a user might prefer gitifyhg,\n\nWell, for me it is exactly the other way around :-). That said, gitifyhg certainly also still has issues and problems, but I am confident it will even better in the coming weeks. And it certainly wouldn't be were it is now without your great work on remote-hg, and also on related improvements you got into git.git. Kudos!\n\n\n> even more importantly, why gitifyhg developers don't contribute to\n> remote-hg.\n\nI can only speak for myself, as a (minor) contributor to both remote-hg and gitifyhg. But here are my reasons why I prefer contributing to remote-hg over gitifyhg:\n\n1) Apparent difference between your goals and mine / those of gitifyhg. I think this is quite visible if one looks at our exchange above. Features that are quite important to me, even crucial, are unimportant for you, or even outright rejected. In contrast, so far with the couple people working on gitifyhg we always managed to arrive at solutions that satisfy all of us. I.e. it seems our ideas and goals are much better aligned within that group.\n\n2) Lack of reactions on pull requests and bug reports on your github pages. Perhaps you never intended this to be used for pull requests / bug reports, but I never (until recently) saw you state that, nor can one read such a statement on your github pages. \n\n3) Not shipping gitifyhg as part of git/contrib but rather as a separate package is important to me, too. It means that we can make new releases whenever we want, not tied to git. Users can install it easily via \"pip\", and I also think it gets a lot more visibility this way.\n\n\n> \n> Also, unlike remote-hg, which basically passes all the tests of\n> gitifyhg, gitifyhg barely passes any tests of remote-hg (three).\n\nHeh, bad, but OK (as I said, my message was based on an older version of remote-hg, and actually also on an older gitifyhg). Thank you for the report, I'll look into it as soon as I can (or somebody else might).\n\nBTW, I just pulled you hg-next branch, and run \"make test\" in that. The tests in test-hg-hg-git.sh actually all failed (with remote-hg). Do I need to do something special for those to work?\n\n\nCheers,\nMax"},{"id":"213086","messageId":"CAMP44s3qAPJtNVsb4gvYd1PunN4c-crxpVJc0K9520eiBO8iwA@mail.gmail.com","threadId":"33358","inReplyTo":"EF2F8946-4F60-4659-9215-6C21C9641AB0@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T06:42:22Z","receivedAt":"2013-04-04T06:42:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 3, 2013 at 6:25 PM, Max Horn wrote:\n> On 03.04.2013, at 03:31, Felipe Contreras wrote:\n\n>> I only learned about it recently, I've looked at the history and to me\n>> it seems rather chaotic, and a lot of the code was simply copied from\n>> git-remote-hg without comment.\n>\n> gitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here:\n> http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/\n\nYeah, I'm aware of that, but look at the README:\n\n---\nTo the best of our knowledge, this is the most robust and usable git\nto hg bridge currently available. It has a large test suite and better\ndocumentation than the alternatives we know about. It has been tested\non several large mercurial repositories (including that of mercurial\nitself and the pypy repository) that break with various other\ngit-to-hg bridge projects and is used daily in normal workflow\nscenarios.\n---\n\nIt reads as though gitifyhg was this marvelous piece of code developed\nindependently, and everything else (including remote-hg) pales in\ncomparison. There's no mention at all of remote-hg until the very\nbitter end where it's mentioned that it's \"heavily inspired by and\nborrows code\" from it, but it's much more than that, it's *based* on\nthis code. When I read the code, not only do I see it's the same\ndesign, has the same function names, the same variables, the same\norder, huge tracks of code are exactly the same, and in fact, I have\ntoo look very carefully to see the differences.\n\nTake a look at this commit:\nhttp://github.com/buchuki/gitifyhg/commit/2c4fd7329fa0db8dd56df3ac8c62fa292580b74e\n\nGeez, that's an awfully nice author sanitize function, but Dusty\nPhillips was not the author, I am, he just added 2 lines of code.\n\nBut what really bothers me is that the first public version of\nremote-hg happened after many many tries and commits, different\ndesigns were discarded based on bad performance, feasibility, or\ncomplexity, and gitifyhg just copies this code and runs with it.\n\nTake a look at this function, which I took a long time to develop,\nclean, and improve so it performs as efficiently as possible through\narduous profiling in huge repositories:\n\n def get_filechanges(self, context, parent):\n modified = set()\n added = set()\n removed = set()\n\n current = context.manifest()\n previous = self.repo[parent].manifest().copy()\n\n for fn in current:\n if fn in previous:\n if (current.flags(fn) != previous.flags(fn) or\ncurrent[fn] != previous[fn]):\n modified.add(fn)\n del previous[fn]\n else:\n added.add(fn)\n removed |= set(previous.keys())\n\n return added | modified, removed\n\nNobody from gitifyhg even bothered to try to understand this function,\nwhat it does, or why, just copied it:\n\nhttp://github.com/buchuki/gitifyhg/commit/a46d518e2b8df5e8339c8caa9fa113642bc7ac3a\n\nIn fact, it's co clear the code was simply copied without much\nthought, that the parent caller was introduced *before* the actual\nfunction:\n\nhttp://github.com/buchuki/gitifyhg/commit/54be060e1928b7e750bdf3981c32d5bc88851ed1\n\nTo me the strategy was clear: copy code of remote-hg until gitifyhg\nworks, then fix a few bugs, add a few features, and then claim\ngitifyhg is superior, even though remote-hg will clearly fix those\nbugs, and add those features soon enough. I don't see why nobody tried\nto contact git.git, cooperate, and improve what is clearly the\noriginal code of gitifyhg.\n\n>>> * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n>>\n>> I ran these test-cases with remote-hg, and the same test-cases pass. I\n>> only had to do minor modifications, most of the failures came from\n>> subtle differences such as different strategies to sanitize authors,\n>> and which branch to pick for HEAD.\n>\n> Yeah, that's because what I wrote was based on the situation before your recent patch series. Glad to see that git/contrib's remote-hg is improving!\n\nNo, that's not true, this test run is from v1.8.2 without the latest\nfix patches, simply the compatibility ones:\n\n========================================================================\ntest session starts\n========================================================================\nplatform linux2 -- Python 2.7.3 -- pytest-2.3.4\ncollected 80 items\n\ntest/test_author.py ........F\ntest/test_clone.py ......xx.........x...x..\ntest/test_notes.py ..FxF\ntest/test_pull.py ....x..xx..\ntest/test_push.py ...FFFFF.FF...x....FFFFFFFFF\ntest/test_special_cases.py ...\n\n=============================================================================\nFAILURES ==============================================================================\n/home/felipec/tmp/gitifyhg/test/helpers.py:118: assert 'totally\n' == 'totally '\n/usr/lib/python2.7/site-packages/sh.py:309: ErrorReturnCode_128:\n/home/felipec/tmp/gitifyhg/test/test_notes.py:107: assert not 'error'\nin 'From hg::file:///tmp/pytest-0/test_simple_push_updates_notes_after_contentful_pull0/hg_base\\n\n 66d7a5d..a8745f0 mas...rror: refs/notes/hg does not point to a\nvalid object!\\nerror: refs/notes/hg-origin does not point to a valid\nobject!\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:77: assert -1 > 0\n/home/felipec/tmp/gitifyhg/test/test_push.py:86: assert -1 > 0\n/home/felipec/tmp/gitifyhg/test/test_push.py:97: assert -1 > 0\n/home/felipec/tmp/gitifyhg/test/test_push.py:117: assert 'default' ==\n'branch_one'\n/home/felipec/tmp/gitifyhg/test/test_push.py:136: assert 'default' ==\n'branch one'\n/home/felipec/tmp/gitifyhg/test/test_push.py:168: assert 'default' ==\n'branch_one'\n/home/felipec/tmp/gitifyhg/test/test_push.py:181: assert -1 > 0\n/home/felipec/tmp/gitifyhg/test/test_push.py:334: assert 'anewbranch'\nin 'no bookmarks set\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:346: assert\n'this_is_a_tag' in 'tip\n0:1b3b36fc0158\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:358: assert\n'this_is_a_tag' in 'tip\n1:7ca4e066c47f\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:376: assert\n'this_is_a_tag' in 'tip\n2:5b8c7a98dfa4\\nan_old_tag 0:af90a856304c\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:391: assert\n'this_is_a_tag' in 'tip\n0:3c2288c2c93b\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:407: assert\n'this_is_a_tag' in 'tip\n1:090867df4300\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:420: assert 'this is a\ntag' in 'tip 0:b7c5bfb3bdbc\\n'\n/home/felipec/tmp/gitifyhg/test/test_push.py:432: assert\n'this_is_a_tag' in 'tip\n1:10504139dfc4\\nan_old_tag 0:b7c5bfb3bdbc\\n'\n/usr/lib/python2.7/site-packages/sh.py:309: ErrorReturnCode_128:\n========================================================= 19 failed,\n52 passed, 9 xfailed in 74.35 seconds\n==========================================================\n\nThe only real bugs is that tags are not pushed, and named branches are\nwrong, the rest are differences in how errors are reported. I doubt\nwhomever ran these tests spent much time analyzing the results.\nCertainly there's no way to think that remote-hg was completely broken\nand couldn't be fixed to pass these.\n\n>>> * improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't...\n>>\n>> I wouldn't call it improved. In some cases the remote-hg result is\n>> better, in others gitifyhg is,\n>\n> I'd love to learn about cases where remote-hg's result is better in your opinion, so that I can see if the mapping in gitifyhg could be improved for those cases.\n\nFor example \"no email quoting email@example.com\" results in \"no email\nquoting \", but I already have the code that does\nthat in remote-hg.\n\n> That said, this part is really quite subjective I guess. In the end, since Mercurial names can be *anything*, one can never get a \"perfect\" mapping. Luckily, for most real repositories out there, user names will be quite sane and remote-hg and gitifyhg will produce identical results. (Although some hg repos out there have some really weird stuff going on. Yuck.)\n\nIndeed, which is why I advocate for an author mapping solution, so if\nthe user is not happy, they can manually fix the wrong authors.\nMoreover, the author sanitizing should be done by 'git fast-import',\nso that people don't have to implement and re-implement the same\nsanitizing code all the time. Also, the mapping should be part of 'git\nfast-import' so it works the same for all solutions.\n\n>>> * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone.\n>>\n>> This is not an issue in remote-hg any more since now we force the\n>> push. It's not nice, but there's no other way to push multiple\n>> bookmarks (aka git branches) to the same branch (aka commit label).\n>\n> Uhh, what? The push is forced? That sounds to me like a much, much bigger issue with remote-hg than anything else ever was, from my point of view. That seems tobe akin to making \"--force\" default to \"git push\", and I don't think anybody here would consider that a good idea.\n\nIt's absolutely nothing like that; with 'git push --force' you\n**loose** commits, with 'hg push --force' you don't, you simply have\nanother head. It's mercurial's fault that multiple bookmarks cannot be\npushed any other way.\n\n>> I doubt these inconsistent states can happen any more, but if they do,\n>\n> Seriously? This is triggered quite frequently in real life. And it will very likely cause somebody to mess up a hg repository they work on. As long is this in, using remote-hg is a total no-go for me. Just consider the following scenario:\n> * user A clones a hg repository into a git repository\n> * user A commits some commits in the git clone\n> * meanwhile, user B pushes changes to the hg repository\n> * user A tries to push his changes to the hg remote\n>\n> The last step causes this result in gitifyhg (similar to what one gets when the remote is a git repos):\n>\n> With remote-hg, you just force push the change, creating a new head in the remote repo. So, yeah, failed pushes which mess up the internal state don't happen anymore. But I rather have those than potentially mess up the upstream repository like that.\n\nUnfortunately that's per mercurial design; you can't have git-like\nbranches any other way.\n\n>> the plan in remote-hg is to simply ignore those revisions, and only\n>> push the ones that have git refs. I have the code for that, but I'll\n>> not be pushing it to git.git for the time being.\n>\n> I am not quite sure what you mean here, but I'll just wait for your code and hope it'll explain itself.\n\nEven if you end with a dangling head because of a failed push, you can\ndo 'hg push -r good_head', and the bad head will be ignored.\n\n>>> * git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping\n>>\n>> This is a minor feature. I've had the code for this for quite some\n>> time, but for the moment I think there are higher priorities.\n>\n> Well, I guess it depends on how you use this. In my daily work with hg repositories, that's a quite important feature.\n\nIt's more important to fix clone, fetch and push failures.\n\n> Actually, I wonder: Are you actually using remote-hg yourself for day-to-day development? Or for any other regular activities? You seem to have quite different usage patterns from me and other people involved with gitifyhg.\n\nNo, I don't, but plenty of people use hg-git, and I'd say remote-hg is\nsuperior, because it does the same as hg-git, and more.\n\n>>> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n>>\n>> I doubt this makes any difference (except for more wasted space).\n>\n> I disagree. Especially since remote-hg does treat local hg repositories differently than remote ones, by not cloning them but rather working with them directly. As soon as somebody uses \"hg strip\" or \"hg graft\", etc. on that, your mark files will contain incorrect data.\n\nThat might be correct, but doing so on a public repository is not a\ngood idea, it causes problems even in git.\n\nWhen I'm done with other tasks I will do some tests to see for sure\nwhat are the real issues, what is merely hypothetical, and what is\nlikely. For the moment worrying a workflow that is actually a bad\npractice is not sensible.\n\n> With a remote hg repository, that is of course not as much of an issue, since you have a local hg clone stored inside of .git/. In theory, the user would never touch that, so nothing in there changes. In reality, though, sometimes the user still has to dig in there and modify things (e.g. to undo a \"bad\" push; although of course for now you \"fixed\" that particular problem by force pushing). Of course in an ideal world, a user never should have to do that, but as long as there are bugs, users may have to. And based on painful experience, it is *much* easier to do that when the marks use the invariant hashes instead of the transient rev ids.\n\nHow do you end up with a bad push in remote-hg?\n\n> As for the wasted space: For a repository with 999,999 commits, the size of the \"marks-hg file should increase from about 1.5 MB to about 5 MB. To use your words: Hardly worth mentioning.\n\nIt is a parenthesis (it was hardly mentioned).\n\n>>> * Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].\n>>\n>> This is literally a three lines fix, and it simply makes one error\n>> nicer. Hardly worth mentioning.\n>\n> Perhaps not for you, but for users who just want to use remote-hg resp. gitifyhg, getting a helpful error message instead of seeing an (to them) unreadable stack trace is quite important. I guess this just shows that we have quite different goals and ideas about how to interact with users of our respective tools :-).\n\nI have a suspicion that gitifyhg converts dates wrong, how is getting\na helpful error message on something the user would rarely (if ever)\ndo, more important than that (something the user always does)? We\nmight have different priorities, but I think mine are correct.\n\nAnd don't speak about the \"goals\", because as I said I already have\nthe fix, saying we have different goals is implying that I don't want\nto fix this issue, as if somehow not fixing a trivial error message\nwould not allow me to achieve my \"goals\". The priorities might be\ndifferent, but the goals are the same, and I think remote-hg is much\ncloser.\n\nAlso, anybody can send patches to the git mailing list, so _my_ goals,\nand _my_ priorities shouldn't matter much.\n\n>>> * The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\n>>> In particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n>>\n>> I've personally checked against multiple versions of Mercurial. It's\n>> possible that some error might slip by, but it would get quickly\n>> noticed.\n>\n> Really? This sounds close to some people who say things like \"I don't need a test suite, I personally run some tests every now and then on my machine.\"\n\nDo you see any compatibility issues reported in the git mailing list,\nor my github[1]? No? KTHXBYE. There _were_ compatibility issues, and\nthose got reported, and fixed, not any more.\n\nAlso, having CI testing doesn't ensure a project has better code, it's\nthe actual code that matters, and so far you haven't proved why\nremote-hg's code would be inherently inferior. Moreover, gitifyhg\ndoesn't seem to have bidirectionality tests, remote-hg does, and\ngitifyhg basically fails all of them, not to mention the ones that\ncompare the output with hg-git's, which has had far many more years of\ndevelopment and testing, and their extensive tests have been harnessed\nby remote-hg.\n\n> Furthermore, you don't seem to document what versions of Mercurial are supposed to work / not work. (Indeed, as far as I can tell, remote-hg has no documentation whatsoever, another difference. Granted, the gitifyhg README is not particular great at this point, but at least it exists and tells people how to get started and where to get help).\n\nWhen a user has a problem with that, we can deal with it. It's not\nhard to do, and in fact it was done only one month ago in gitifyhg.\nNothing inherently different.\n\n> In contrast, the gitifyhg README clearly states that it \"requires at least Mercurial 1.9\". And its setup.py refuses to install it if the Mercurial version is too old. Again, for us devs that's not very important, but for users, I think it is. In recent months, I had to provide assistance with using hg to tons of people (*sigh*), and old Mercurial versions came up in a considerable portion of those (perhaps 30-40% or so).\n\nremote-hg certainly works on versions older than 1.9, again, I find it\nannoying that you claim to know what is important for users, as if\nsomehow knowing that gitifyhg doesn't work with the user's version of\nmercurial (e.g. 1.8) is better than remote-hg's situation; where it\n*actually works*, but it's not mentioned. Yeah, mentioning that it\ndoesn't work is better than working, right.\n\n>>> * Renaming a gitifyhg remote just works [5]. Doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember).\n>>\n>> Yeah, now you can change the alias of the remote, but you can't change\n>> the remote url.\n>\n> That's simply wrong. You still can change the remote URL, it will just lead to the creation of a fresh separate local clone.\n\nExactly the same will happen with remote-hg when you change the alias.\nEither creating a new local clone is \"working\", or it's not, you can't\nhave your cake and eat it at the same time. remote-hg reclones on\nalias change, gitifyhg reclones on URL change. There is no advantage\nhere.\n\n> In contrast, with remote-hg, renaming the remote will create a fresh local clone, while changing the remote URL will *not* do that -- instead, the changes from the new remote will be pulled into the existing local clone. Which in some cases may be exactly what you want (e.g. if a repository just moved to a different remote URL). But in other cases, it won't be, namely when the repository at the new URL contains different content. This is not that unlikely when you consider that it comment Mercurial workflow to use separate repositories for different branches.\n\nIt doesn't matter. The \"extra content\" that you get from the different\nURL will just create that; extra content, both in the local git, and\nmercurial repos. Since remote-hg will selectively push specific\nrevisions, that extra content will simply remain there, ignored.\n\n>> This is not really an advantage, simply an almost\n>> imperceptible different choice.\n>\n> These are indeed different design choices, but at least to me, they are very much perceptible :-). And we made this design choice quite consciously, after looking at how it is done in remote-hg, and not liking that.\n\nThis is not design, a few lines of code would change the behavior. And\nyou still haven't shown a single *important* use case where a user\nwould decide, you know what, yeah, I'll use gitifyhg because of that;\n\"I rename remote aliases a lot\", \"My upstream repo gets constantly\nrebased\" are very, very, unlikely phrases any user will ever utter.\n\nAnd ultimately it doesn't matter, because if it's somehow decided that\none way is better than the other, we can switch it rather easily\n(because they are not design decisions). So again, no, there's nothing\ninherently superior here, merely subtle different behavior.\n\n> Anyway: At least in my day-to-day operations, I occasionally rename a remote (very rare, but it happens). So far I never had to change a remote URL. Of course that is just me, perhaps others occasionally (well, more of than me :-) have to change remote URLs. But as I said, that's still possible in gitifyhg.\n\nAnd I've changed the remote URL plenty of times, and again, changing\nthe alias works just fine as well.\n\n>> I still don't see any good reason why a user might prefer gitifyhg,\n>\n> Well, for me it is exactly the other way around :-). That said, gitifyhg certainly also still has issues and problems, but I am confident it will even better in the coming weeks. And it certainly wouldn't be were it is now without your great work on remote-hg, and also on related improvements you got into git.git. Kudos!\n\nYou know what would be a proper way to thank? Mention where most of\nthe code and design came from in the README, and _at least_ mention\nwhy you decided to work on your own rather than cooperate. When I\nannounced the work on remote-hg I discussed with the authors of other\nsolutions to try to explain why this work was needed until I\ndemonstrated that this was indeed superior, and I didn't even borrowed\ncode. I also provided a public summary when I announced it in my\nblog[2].\n\n>> even more importantly, why gitifyhg developers don't contribute to\n>> remote-hg.\n>\n> I can only speak for myself, as a (minor) contributor to both remote-hg and gitifyhg. But here are my reasons why I prefer contributing to remote-hg over gitifyhg:\n>\n> 1) Apparent difference between your goals and mine / those of gitifyhg. I think this is quite visible if one looks at our exchange above. Features that are quite important to me, even crucial, are unimportant for you, or even outright rejected. In contrast, so far with the couple people working on gitifyhg we always managed to arrive at solutions that satisfy all of us. I.e. it seems our ideas and goals are much better aligned within that group.\n\nAgain, my goals are irrelevant, if you present a good case for a\npatch, it will be merged by the maintainer, Junio, I'm not the\nmaintainer. But be prepared for argumentation from me, and others.\n\nAnd no, I haven't rejected any patch, I couldn't reject a patch sent\nto the git mailing list even if I wanted. I have only argued against\nproposals, and if you give up when somebody argues against your ideas,\nperhaps they were not so good in the first place.\n\nBut most of the \"features\" that you mentioned I said I ALREADY HAVE\nTHE PATCH FOR IT. So don't say we have different goals.\n\n> 2) Lack of reactions on pull requests and bug reports on your github pages. Perhaps you never intended this to be used for pull requests / bug reports, but I never (until recently) saw you state that, nor can one read such a statement on your github pages.\n\nI was not working on remote-hg. But it doesn't matter, git's\ndevelopment happens in the git mailing list, and anybody can send\npatches.\n\n> 3) Not shipping gitifyhg as part of git/contrib but rather as a separate package is important to me, too. It means that we can make new releases whenever we want, not tied to git. Users can install it easily via \"pip\", and I also think it gets a lot more visibility this way.\n\n% wget http://raw.github.com/felipec/git/fc/remote/hg/contrib/remote-helpers/git-remote-hg\n-O ~/bin/git-remote-hg\n\nThere, you now have the latest and greatest version of remote-hg, you\ndon't need to wait for git.git to make a release. In fact, I'm in\ncontact with a few people that are having issues that are running\nprecisely this version; the latest and greatest.\n\n>> Also, unlike remote-hg, which basically passes all the tests of\n>> gitifyhg, gitifyhg barely passes any tests of remote-hg (three).\n>\n> Heh, bad, but OK (as I said, my message was based on an older version of remote-hg, and actually also on an older gitifyhg). Thank you for the report, I'll look into it as soon as I can (or somebody else might).\n>\n> BTW, I just pulled you hg-next branch, and run \"make test\" in that. The tests in test-hg-hg-git.sh actually all failed (with remote-hg). Do I need to do something special for those to work?\n\nNo, they should just work. Perhaps you have an old version of hg-git\n(I have v0.4). You can check the errors with\nGIT_TEST_OPTS=\"--verbose\".\n\nCheers.\n\n[1] https://github.com/felipec/git/issues\n[2] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/\n\n-- \nFelipe Contreras\n"},{"id":"213088","messageId":"CAMP44s3HcLji22JDoSVZG_cLca8LXTbUPuVv8SbAM1yTqn8zcw@mail.gmail.com","threadId":"33358","inReplyTo":"CAMP44s3qAPJtNVsb4gvYd1PunN4c-crxpVJc0K9520eiBO8iwA@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T06:46:47Z","receivedAt":"2013-04-04T06:46:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 4, 2013 at 12:42 AM, Felipe Contreras\n wrote:\n> On Wed, Apr 3, 2013 at 6:25 PM, Max Horn wrote:\n>> On 03.04.2013, at 03:31, Felipe Contreras wrote:\n>\n>>> I only learned about it recently, I've looked at the history and to me\n>>> it seems rather chaotic, and a lot of the code was simply copied from\n>>> git-remote-hg without comment.\n>>\n>> gitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here:\n>> http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/\n\nPlease don't CC the gitifyhg mailing list, unlike vger mailing lists\n(or any other sane list), it doesn't accept mail from non-subscribers,\nwhich makes communication with outsiders much more difficult, as\ndemonstrated by this.\n\n---\nWe're writing to let you know that the group you tried to contact\n(gitifyhg) may not exist, or you may not have permission to post\nmessages to the group. A few more details on why you weren't able to\npost:\n\n * You might have spelled or formatted the group name incorrectly.\n * The owner of the group may have removed this group.\n * You may need to join the group before receiving permission to post.\n * This group may not be open to posting.\n---\n\n-- \nFelipe Contreras\n"},{"id":"213092","messageId":"836B6357-AF21-4DE7-B9D7-13CAB0170599@quendi.de","threadId":"33358","inReplyTo":"CAMP44s3HcLji22JDoSVZG_cLca8LXTbUPuVv8SbAM1yTqn8zcw@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-04-04T09:07:27Z","receivedAt":"2013-04-04T09:07:27Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 04.04.2013, at 08:46, Felipe Contreras wrote:\n\n> On Thu, Apr 4, 2013 at 12:42 AM, Felipe Contreras\n> wrote:\n>> On Wed, Apr 3, 2013 at 6:25 PM, Max Horn wrote:\n>>> On 03.04.2013, at 03:31, Felipe Contreras wrote:\n>> \n>>>> I only learned about it recently, I've looked at the history and to me\n>>>> it seems rather chaotic, and a lot of the code was simply copied from\n>>>> git-remote-hg without comment.\n>>> \n>>> gitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here:\n>>> http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/\n> \n> Please don't CC the gitifyhg mailing list, unlike vger mailing lists\n> (or any other sane list), it doesn't accept mail from non-subscribers,\n> which makes communication with outsiders much more difficult, as\n> demonstrated by this.\n\nI changed the settings of the gitifyhg list settings to accept emails from anybody.\n\nMoreover, I would appreciate if you could refrain from injecting all those snide side remarks, such as the one you just needlessly made about how moderated mailing lists are insane."},{"id":"213093","messageId":"CAMP44s1yseJEgb4H7REJARHHO19f5BSD=ijQi4kwqcQZei=zWg@mail.gmail.com","threadId":"33358","inReplyTo":"836B6357-AF21-4DE7-B9D7-13CAB0170599@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T09:35:43Z","receivedAt":"2013-04-04T09:35:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 4, 2013 at 3:07 AM, Max Horn wrote:\n>\n> On 04.04.2013, at 08:46, Felipe Contreras wrote:\n>\n>> On Thu, Apr 4, 2013 at 12:42 AM, Felipe Contreras\n>> wrote:\n>>> On Wed, Apr 3, 2013 at 6:25 PM, Max Horn wrote:\n>>>> On 03.04.2013, at 03:31, Felipe Contreras wrote:\n>>>\n>>>>> I only learned about it recently, I've looked at the history and to me\n>>>>> it seems rather chaotic, and a lot of the code was simply copied from\n>>>>> git-remote-hg without comment.\n>>>>\n>>>> gitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here:\n>>>> http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/\n>>\n>> Please don't CC the gitifyhg mailing list, unlike vger mailing lists\n>> (or any other sane list), it doesn't accept mail from non-subscribers,\n>> which makes communication with outsiders much more difficult, as\n>> demonstrated by this.\n>\n> I changed the settings of the gitifyhg list settings to accept emails from anybody.\n\nCool.\n\n> Moreover, I would appreciate if you could refrain from injecting all those snide side remarks, such as the one you just needlessly made about how moderated mailing lists are insane.\n\nI did not say that, gitifyhg's mailing list was not _moderated_, it\n*automatically* rejected all non-subscriber email without any\n_moderation_; that is insane in my opinion, but a lot of mailing lists\ndo that.\n\n-- \nFelipe Contreras\n"},{"id":"213099","messageId":"515d9741985ca_69fd13fde181671a@nysa.mail","threadId":"33358","inReplyTo":"7v8v50brfn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T15:07:45Z","receivedAt":"2013-04-04T15:07:45Z","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> > On Tue, Apr 2, 2013 at 1:58 PM, Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >>\n> >>> We can't use stdout for that in remote helpers.\n> >>>\n> >>> Signed-off-by: Felipe Contreras \n> >>> ---\n> >>\n> >> You may want to clarify \"buggy output\" a bit. Will mercurial\n> >> forever be broken? Some versions of Hg emit [[[it is unclear for\n> >> Junio to tell what it is to fill this blank]]] to its output that\n> >> we want to ignore?\n> >\n> > The problem is that mercurial's code is kind of hardcoded to run under\n> > mercurial's UI, so it throws messages around willynillingly, like:\n> >\n> > searching for changes\n> > no changes found\n> >\n> > And they can't be turned off. Theoretically we could override\n> > mercurial's UI class, but I think that has the potential to create\n> > more problems, it's not worth at this point in time.\n> \n> Oh, I totally agree with you _after_ reading that explanation.\n> \n> You just shouldn't let me waste your time to explain that to me in\n> this exchange, and you could have done so by writing a clearer log\n> message. That's all.\n\nI saw that you update the commit message without consulting here first to:\n\n---\nremote-hg: redirect unnecessary mercurial output\n \nMercurial emits messages like \"searching for changes\", \"no changes\nfound\", etc. meant for the use of its own UI layer, which is of no\nuse for our remote helper. Squelch them.\n---\n\nThis is not correct. This patch does _not_ squelch the output, it's redirecting\nit to standard error, so the user actually sees it now, and we do that not\nbecause the output is \"unnecessary\", but because it *breaks* the pipe between\nthe transport helper and remote helper. I'll reroll with the updated commit message.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213125","messageId":"CAMP44s02PUGctgacuGRw3p8uEXhowZJWJjdq0g9aO9bBbpnv2w@mail.gmail.com","threadId":"33358","inReplyTo":"2670C2C0-E30F-47DA-8901-899FEE11059E@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T16:14:33Z","receivedAt":"2013-04-04T16:14:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 2, 2013 at 4:23 PM, Max Horn wrote:\n\n> I'll try to list some of remaining differences, mostly (in my biased opinion) improvements on the gitifyhg side. Note that some of these might be outdated with felipe's recent changes, i.e. I have not yet had time to review and/or test them all. So please bear that in mind.\n\nI've implemented a lot of these, cleaned them up, and pushed them, the\nones that will be integrated:\nhttp://github.com/felipec/git/tree/fc/remote/hg-next\n\nThe ones that won't (at least not without more discussion):\nhttp://github.com/felipec/git/tree/fc/remote/hg-gitifyhg-compat\n\n> * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg)\n\nI don't think there's anything inherently better about these tests,\nwith the compatibility patches here are the results on v0.8 running\nremote-hg:\n\n=========================================================== test\nsession starts ===========================================================\nplatform linux2 -- Python 2.7.3 -- pytest-2.3.4\ncollected 80 items\n\ntest/test_author.py ........F\ntest/test_clone.py ......xx.........x...x..\ntest/test_notes.py ..Fx.\ntest/test_pull.py ....x..xx..\ntest/test_push.py ..........F...x........FF...\ntest/test_special_cases.py ...\n\n============================================= 5 failed, 66 passed, 9\nxfailed in 75.52 seconds =============================================\n\n> * improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't...\n\nThis is not true; after checking the code, remote-hg can't possibly\nfail, if it does, so does gitifyhg. I guarantee it. The only\ndifferences are cosmetic.\n\nThat being said, I'll integrate a patch that I believe produces\nsuperior sanitation than gitifyhg's, and passes the gitifyhg test (as\nyou can see above) (for the most part):\n\nhttps://github.com/felipec/git/commit/c0e363915eb6459233e37d5082fb2ff7c7c727b4\n\n> * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone.\n\nAfter the change to force=true, let's see if this happens any more in\nremote-hg (Doubt it).\n\n> * git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping\n\nEasy:\nhttps://github.com/felipec/git/commit/2294fb445f5c018a39f421cba70e4d8510c04c89\n\nI will not integrate this for the moment, there must be a better way\nto interact with transport-helper to update these.\n\n> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n\nI will investigate the pros and cons of this, but either way it's not\nsomething people are going to immediately need (I doubt the\nsemi-broken states will happen again).\n\n> * Better handling of various hg errors, see e.g. [2]. More work is still needed there with both tools, though [3].\n\nNo idea why something so trivial was mentioned:\nhttps://github.com/felipec/git/commit/d12e35d23b9d26d384c3dbbce25a09720ccbceff\n\n> * Support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)\n\nThis was already merged to git.git:\nhttps://git.kernel.org/cgit/git/git.git/commit/?id=32f370f62177b505daf96aaf711c0249d881b6c0\n\n(link might change)\n\n> * The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\n> In particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n\nThis is nice, but doesn't translate necessarily to anything tangible\nfor the user. remote-hg, like all git.git, has good development\npractices, which minimizes the risks of regressions.\n\n> * Renaming a gitifyhg remote just works [5]. Doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember).\n\nChanging a remote-hg URL remote just works. Potato potato.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213127","messageId":"7vr4iqjm3y.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"515d9741985ca_69fd13fde181671a@nysa.mail","subject":"Re: [PATCH 07/13] remote-hg: redirect buggy mercurial output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-04T16:29:05Z","receivedAt":"2013-04-04T16:29:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I saw that you update the commit message without consulting here first to:\n>\n> ---\n> remote-hg: redirect unnecessary mercurial output\n> \n> Mercurial emits messages like \"searching for changes\", \"no changes\n> found\", etc. meant for the use of its own UI layer, which is of no\n> use for our remote helper. Squelch them.\n> ---\n>\n> This is not correct. This patch does _not_ squelch the output, it's redirecting\n> it to standard error, so the user actually sees it now, and we do that not\n> because the output is \"unnecessary\", but because it *breaks* the pipe between\n> the transport helper and remote helper. I'll reroll with the updated commit message.\n\nI actually \"consulted\" by asking you what you meant by \"buggy\". I\njust misread/misunderstood your response in prose.\n\nAn update in the patch form obviously would not risk such a\nmisunderstanding ;-)\n\nThanks.\n"},{"id":"213141","messageId":"871uaqrwrp.fsf@59A2.org","threadId":"33358","inReplyTo":"CAMP44s3DETFBhexPhEEMP1TZGNrc91266=t16H2t_+VB_4V38w@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Jed Brown","fromEmail":"jed@59a2.org","sentAt":"2013-04-04T18:11:38Z","receivedAt":"2013-04-04T18:11:38Z","isPatch":true,"sender":{"key":"jed@59a2.org","avatar":"https://gravatar.com/avatar/1391d04d82555f9058a9fdf5eead233e909a48e40480db31fc554e7afeb301da?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> I still don't see any good reason why a user might prefer gitifyhg,\n> even more importantly, why gitifyhg developers don't contribute to\n> remote-hg.\n\nFelipe, I read your blog announcement [1] and got the impression that\nremote-hg was ready for daily use. When I tried to use it, it promptly\ncrashed in my first attempt to clone. I opened up the script, fixed\nwhatever caused the first stack trace and made it slighly further before\nit crashed again. I couldn't tell what was expected to work, what was a\nknown problem, and what was an unknown problem. Many things clearly did\nnot work and it had the look of a project that was not getting active\nuse. I felt that it was wildly oversold and that putting it into\ngit.git was premature.\n\nI tried gitifyhg later and it basically worked out of the box. All\nknown problems were marked by 'xfail' test cases. At that time,\nremote-hg failed almost all the gitifyhg tests. I contributed a few\nthings to gitifyhg, including the notes support (essential when talking\nvia email with other people using Mercurial). Since then, the last\nmajor project I'm involved with has switched to Git so I rarely need\ngitifyhg or remote-hg any more.\n\n\n\nFWIW, I also thought Dusty's original announcement oversold gitifyhg, but\nit was closer to the truth and upon cloning the repo, it was more clear\nwhat didn't work. The early history of gitifyhg is quite chaotic and I\ndidn't realize at first how much code turned out to be borrowed from\nremote-hg. I don't know whether you wrote all of remote-hg or borrowed\nsignificant parts from elsewhere. To be honest, I don't really care,\nbut it would be good to coalesce around one project that is well-tested\nand has documented behavior so that the poor folks stuck with Mercurial\nupstreams can have dependable behavior.\n\n[1] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/\n"},{"id":"213153","messageId":"7vip42i1r0.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"871uaqrwrp.fsf@59A2.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-04T18:34:11Z","receivedAt":"2013-04-04T18:34:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jed Brown writes:\n\n> ... I felt that it was wildly oversold and that putting it into\n> git.git was premature.\n>\n> I tried gitifyhg later and it basically worked out of the box. All\n> known problems were marked by 'xfail' test cases. At that time,\n> remote-hg failed almost all the gitifyhg tests. I contributed a few\n> things to gitifyhg, including the notes support (essential when talking\n> via email with other people using Mercurial). Since then, the last\n> major project I'm involved with has switched to Git so I rarely need\n> gitifyhg or remote-hg any more.\n>\n> FWIW, I also thought Dusty's original announcement oversold gitifyhg, but\n> it was closer to the truth and upon cloning the repo, it was more clear\n> what didn't work.\n\nSo,... is there a concrete proposal for _me_ to act on? Do you want\nto see contrib/remtote-hg out of my tree, and have it compete with\nthe other one (which also shouldn't be in my tree) in the open?\n"},{"id":"213155","messageId":"CAMP44s3zm+-220Xpqv_=JkJ=g2pS79hUNjacVZ=JejitcG=B8A@mail.gmail.com","threadId":"33358","inReplyTo":"871uaqrwrp.fsf@59A2.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T18:41:06Z","receivedAt":"2013-04-04T18:41:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 4, 2013 at 12:11 PM, Jed Brown wrote:\n> Felipe Contreras writes:\n>\n>> I still don't see any good reason why a user might prefer gitifyhg,\n>> even more importantly, why gitifyhg developers don't contribute to\n>> remote-hg.\n>\n> Felipe, I read your blog announcement [1] and got the impression that\n> remote-hg was ready for daily use. When I tried to use it, it promptly\n> crashed in my first attempt to clone. I opened up the script, fixed\n> whatever caused the first stack trace and made it slighly further before\n> it crashed again. I couldn't tell what was expected to work, what was a\n> known problem, and what was an unknown problem. Many things clearly did\n> not work and it had the look of a project that was not getting active\n> use. I felt that it was wildly oversold and that putting it into\n> git.git was premature.\n\nWhere is the evidence? You say remote-hg doesn't work, I say it does,\nthe difference is that I have evidence to prove it.\n\nThere's no bug report, no mail, no log of any kind, no repository to\ncheck, no nothing. What are developers supposed to do with this\ncomment? Nothing, it's not constructive.\n\n> I tried gitifyhg later and it basically worked out of the box. All\n> known problems were marked by 'xfail' test cases. At that time,\n> remote-hg failed almost all the gitifyhg tests.\n\nBecause gitifyhg tests are testing gitifyhg, not proper behavior. For example:\n\ndef test_push_conflict_default(git_dir, hg_repo):\n git_repo = clone_repo(git_dir, hg_repo)\n sh.cd(hg_repo)\n make_hg_commit(\"b\")\n sh.cd(git_repo)\n make_git_commit(\"c\")\n assert sh.git.push(_ok_code=1).stderr.find(\"master -> master\n(non-fast-forward)\") > 0\n\nremote-hg doesn't fail with the non-fast-forward error, in fact, it\ndoesn't fail at all, it pushes correctly, and that's reported as a\nfailure.\n\n> I contributed a few\n> things to gitifyhg, including the notes support (essential when talking\n> via email with other people using Mercurial). Since then, the last\n> major project I'm involved with has switched to Git so I rarely need\n> gitifyhg or remote-hg any more.\n\nSo what is the purpose of this anecdote? Are you going to provide\nsomething of value, or is this just an attempt to root for the project\nyou have contributed to?\n\n> FWIW, I also thought Dusty's original announcement oversold gitifyhg, but\n> it was closer to the truth and upon cloning the repo, it was more clear\n> what didn't work.\n\nThis is *one* data-point, you can't make such overreaching\ngeneralizations from *one* data-point; you will often be wrong.\n\n> The early history of gitifyhg is quite chaotic and I\n> didn't realize at first how much code turned out to be borrowed from\n> remote-hg. I don't know whether you wrote all of remote-hg or borrowed\n> significant parts from elsewhere. To be honest, I don't really care,\n> but it would be good to coalesce around one project that is well-tested\n> and has documented behavior so that the poor folks stuck with Mercurial\n> upstreams can have dependable behavior.\n\nIndeed, and mails like this don't help one iota to achieve that. We\nneed data, arguments, and code, and you are not providing any.\n\nNow, if you can go fetch the log of the error you had, that would be\ngreat, otherwise I'll turn to something productive, like improving\nremote-hg.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213162","messageId":"87vc82qfws.fsf@59A2.org","threadId":"33358","inReplyTo":"CAMP44s3zm+-220Xpqv_=JkJ=g2pS79hUNjacVZ=JejitcG=B8A@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Jed Brown","fromEmail":"jed@59a2.org","sentAt":"2013-04-04T19:01:07Z","receivedAt":"2013-04-04T19:01:07Z","isPatch":true,"sender":{"key":"jed@59a2.org","avatar":"https://gravatar.com/avatar/1391d04d82555f9058a9fdf5eead233e909a48e40480db31fc554e7afeb301da?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> Where is the evidence? You say remote-hg doesn't work, I say it does,\n> the difference is that I have evidence to prove it.\n\nThere are many projects that don't do what they claim. I gave remote-hg\na few minutes and moved on since (at the time) it didn't seem\ninteresting enough to be worth the effort of making proper bug reports.\nThere's a lot of low-quality code in the world and I'm willing to\ntolerate a certain false-positive rate. I apologize for misdiagnosing\nyour project and I'm happy to believe that you have since fixed the\nbugs. I was merely answering you question of why some of us contributed\nto gitifyhg in preference to remote-hg.\n\nI see no value in dwelling on the value judgement I made a few months\nago. Additionally, I have almost no use for either project any more.\n\n> remote-hg doesn't fail with the non-fast-forward error, in fact, it\n> doesn't fail at all, it pushes correctly, and that's reported as a\n> failure.\n\nI don't agree that force-pushing by default is \"correct\" behavior.\n"},{"id":"213171","messageId":"87sj36qewa.fsf@59A2.org","threadId":"33358","inReplyTo":"7vip42i1r0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Jed Brown","fromEmail":"jed@59a2.org","sentAt":"2013-04-04T19:23:01Z","receivedAt":"2013-04-04T19:23:01Z","isPatch":true,"sender":{"key":"jed@59a2.org","avatar":"https://gravatar.com/avatar/1391d04d82555f9058a9fdf5eead233e909a48e40480db31fc554e7afeb301da?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> So,... is there a concrete proposal for _me_ to act on? Do you want\n> to see contrib/remtote-hg out of my tree, and have it compete with\n> the other one (which also shouldn't be in my tree) in the open?\n\nThree months ago, I would have said yes. Now I don't know. It looks\nlike remote-hg has improved and is perhaps stable enough to remain, but\nI think it needs a much more complete test suite [1] and some visible\ndocumentation about its mapping semantics. There is no way a change\nlike \"force-push by default\" should come without the user knowing about\nit. (I don't think force-push should become the default in any case,\nbut something is wrong with the process if there isn't a good way to\ncommunicate such behavioral turmoil.) A separate project making its own\nreleases has a more visible place to indicate such changes.\n\n[1] Max and I have no love for the \"obfuscated shell scripting\" in\ngitifyhg's 'py.test'- and 'sh'-based test suite, and we expressed early\non that we'd rather have git-style shell scripts. So while porting\nthese would provide a good start, they can't just be dropped into\ngit.git.\n"},{"id":"213176","messageId":"CAMP44s2YbJEtpBXHyUGrPta8O8W3fT_TJJ0Cq4BhSJGk1ODPOQ@mail.gmail.com","threadId":"33358","inReplyTo":"87sj36qewa.fsf@59A2.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-04T19:45:35Z","receivedAt":"2013-04-04T19:45:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 4, 2013 at 1:23 PM, Jed Brown wrote:\n> Junio C Hamano writes:\n>\n>> So,... is there a concrete proposal for _me_ to act on? Do you want\n>> to see contrib/remtote-hg out of my tree, and have it compete with\n>> the other one (which also shouldn't be in my tree) in the open?\n>\n> Three months ago, I would have said yes. Now I don't know. It looks\n> like remote-hg has improved and is perhaps stable enough to remain,\n\nReally? There have been 22 changes since 3 months ago. You think a\nproject goes from droppable to decent in 22 commits? The fact that you\nhit a bug doesn't make a project unworthy. I thought you said you were\nnot going to dwell in your value judgement.\n\n> but\n> I think it needs a much more complete test suite [1] and some visible\n> documentation about its mapping semantics.\n\nI don't see anything particularly valuable in gitifyhg's test suite.\nShow me a single test-case that remote-hg fails that would make sense\nto port, then we'll talk.\n\n> There is no way a change\n> like \"force-push by default\" should come without the user knowing about\n> it. (I don't think force-push should become the default in any case,\n> but something is wrong with the process if there isn't a good way to\n> communicate such behavioral turmoil.) A separate project making its own\n> releases has a more visible place to indicate such changes.\n\nTell me, what is the worst case scenario a forced push will create?\nWhat would be this terrible turmoil?\n\n> [1] Max and I have no love for the \"obfuscated shell scripting\" in\n> gitifyhg's 'py.test'- and 'sh'-based test suite, and we expressed early\n> on that we'd rather have git-style shell scripts. So while porting\n> these would provide a good start, they can't just be dropped into\n> git.git.\n\nOh yes they can, it's very easy to port (although annoying), I ported\nquite a few of them because it was impossible to debug through py.test\n(because stderr was incompletely shown), so I was forced to do that,\nbut again, I didn't see much value in them and deleted them. Maybe if\nwe had some complex striping on errors, but not at the moment.\n\nI would love to be proven wrong; show me a single test that is so\nsorely needed in remote-hg.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213254","messageId":"515e8ab11a679_3cb6f57e181657@nysa.mail","threadId":"33358","inReplyTo":"CALWbr2w2jjBmO9pTrw12UGKGC94MQqg6mZynLACLT7B3eoz8VQ@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-05T08:26:25Z","receivedAt":"2013-04-05T08:26:25Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Antoine Pelisse wrote:\n> >> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n> >\n> > I doubt this makes any difference (except for more wasted space).\n> \n> I think this is definitely wrong. If you happen to strip a changeset\n> from the mercurial repository, and redo a completely different commit\n> on top of it, the new commit will never be seen on git end (because it\n> will have the same rev id and will thus be identified as identical\n> from git point of view).\n\nThat is true. I've written the code to use SHA-1 nodeids inststead andd this\nparticular scenario works correctly, I just need to figure a way to discard the\nold ones.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213264","messageId":"CAMP44s3eMe9O12Jp7LRoVYy-Hf_9+cuVTcex5u51yERj+xKO8w@mail.gmail.com","threadId":"33358","inReplyTo":"CAMP44s02PUGctgacuGRw3p8uEXhowZJWJjdq0g9aO9bBbpnv2w@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-05T11:45:13Z","receivedAt":"2013-04-05T11:45:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 4, 2013 at 10:14 AM, Felipe Contreras\n wrote:\n> On Tue, Apr 2, 2013 at 4:23 PM, Max Horn wrote:\n\n>> * internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states.\n>\n> I will investigate the pros and cons of this, but either way it's not\n> something people are going to immediately need (I doubt the\n> semi-broken states will happen again).\n\nAnd another one bites the dust:\nhttps://github.com/felipec/git/commits/fc/remote/hg-noteids\n\n-- \nFelipe Contreras\n"},{"id":"213324","messageId":"BA2657F2-708B-434E-87D2-D6371806E2D3@quendi.de","threadId":"33358","inReplyTo":"CAMP44s3qAPJtNVsb4gvYd1PunN4c-crxpVJc0K9520eiBO8iwA@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-04-05T22:30:51Z","receivedAt":"2013-04-05T22:30:51Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nWhile I am not really interested in exchanging any further emails or any other form of communication with Felipe, as I find his vitriolic style of communication unbearable, I feel compelled to reply to a few points. I'll probably regret this... anyway, I promise this will be my last mail in this thread. Even though I fully expect to receive a barrage of hostile and aggressive replies by Felipe. So be it, /dev/null has plenty space left.\n\n\nOK, I'll try to keep a professional tone from now on :-).\n\n\nOn 04.04.2013, at 08:42, Felipe Contreras wrote:\n\n[...]\n\n>>>> * The gitifyhg test suite is run after each push on Travis CI against several git / mercurial combinations [4].\n>>>> In particular, unlike all other remote-hg implementations I know, we explicitly promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now). This has been a frequent issue for me with the msysgit remote-hg\n>>> \n>>> I've personally checked against multiple versions of Mercurial. It's\n>>> possible that some error might slip by, but it would get quickly\n>>> noticed.\n>> \n>> Really? This sounds close to some people who say things like \"I don't need a test suite, I personally run some tests every now and then on my machine.\"\n> \n> Do you see any compatibility issues reported in the git mailing list,\n> or my github[1]? No? KTHXBYE. There _were_ compatibility issues, and\n> those got reported, and fixed, not any more.\n\nPlease consider that the willingness of people to collaborate with you in any way is directly related to how you treat them. That includes bug reports. The way you acted towards Jed, who was very calmly and matter-of-factly explaining things, was IMHO completely inappropriate and unacceptable. Indeed, I should augment my list of reasons why people might not want to contribute to remote-hg by one major bullet point: You. And please, don't feel to compelled to tell us that Junio is really the maintainer of remote-hg and not you: Whether this is true or not doesn't matter for this point.\n\n\n> remote-hg certainly works on versions older than 1.9, again\n\nThat's plain wrong. Indeed, remote-hg is using hg interfaces that were only introduced in 1.9. As such, I would be quite surprised if remote-hg worked with older hg versions, but I don't see why I should bother to test... Hmm, wait, I see a reason:\n\n> , I find it\n> annoying that you claim to know what is important for users, as if\n> somehow knowing that gitifyhg doesn't work with the user's version of\n> mercurial (e.g. 1.8) is better than remote-hg's situation; where it\n> *actually works*, but it's not mentioned. Yeah, mentioning that it\n> doesn't work is better than working, right.\n\nI'll leave it to everybody to read what you wrote there, and contrast it with the following, and draw their own conclusions...\n\nThe reason why I did not write what exactly is wrong with remote-hg in hg 1.8 and older is that it is so obvious that I didn't think anybody would need handholding to verify it or find out the details :-). But since you \"asked\" for it:\n\n\n$ hg --version\nMercurial Distributed SCM (version 1.8.4)\n(see http://mercurial.selenic.com for more information)\n\nCopyright (C) 2005-2011 Matt Mackall and others\nThis is free software; see the source for copying conditions. There is NO\nwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n$ git clone hg::foobar/ foobar.git\nCloning into 'foobar.git'...\nTraceback (most recent call last):\n File \"/Users/mhorn/bin/git-remote-hg\", line 846, in \n sys.exit(main(sys.argv))\n File \"/Users/mhorn/bin/git-remote-hg\", line 819, in main\n fix_path(alias, peer or repo, url)\n File \"/Users/mhorn/bin/git-remote-hg\", line 765, in fix_path\n repo_url = util.url(repo.url())\nAttributeError: 'module' object has no attribute 'url'\n\nIndeed, util.url was only added in 1.9.3. OK, let's work around that. Then local clones work. But of course in reality, most users will want to interact with a remote repository. But that's still broken:\n\n$ git clone hg::ssh://hg@bitbucket.org/fingolfin/test-gitifyhg\nCloning into 'test-gitifyhg'...\nTraceback (most recent call last):\n File \"/Users/mhorn/bin/git-remote-hg\", line 1138, in \n sys.exit(main(sys.argv))\n File \"/Users/mhorn/bin/git-remote-hg\", line 1107, in main\n repo = get_repo(url, alias)\n File \"/Users/mhorn/bin/git-remote-hg\", line 284, in get_repo\n peer, dstpeer = hg.clone(myui, {}, url, local_path, update=False, pull=True)\nTypeError: clone() got multiple values for keyword argument 'pull'\n\n\nRight, clone() changed. And some more stuff. See . \n\nThere also was a good reason why I stopped at that point, but I don't remember the details right now. And quite frankly, I have zero incentive to even try to remember. But anyway, I don't think it's that useful to add support for 1.8, too, since one can't get back much further anyway. And upgrading to a newer Mercurial is (a) quite easy (even if you don't have root, just install it into $HOME), and (b) using a newer Mercurial version is a good idea for other reasons, too.\n\n[...]\n\n> \n>>> Also, unlike remote-hg, which basically passes all the tests of\n>>> gitifyhg, gitifyhg barely passes any tests of remote-hg (three).\n>> \n>> Heh, bad, but OK (as I said, my message was based on an older version of remote-hg, and actually also on an older gitifyhg). Thank you for the report, I'll look into it as soon as I can (or somebody else might).\n>> \n>> BTW, I just pulled you hg-next branch, and run \"make test\" in that. The tests in test-hg-hg-git.sh actually all failed (with remote-hg). Do I need to do something special for those to work?\n> \n> No, they should just work. Perhaps you have an old version of hg-git\n> (I have v0.4). You can check the errors with\n> GIT_TEST_OPTS=\"--verbose\".\n\nYup, that was it, thanks. It would be kinda nice if the test code could check for suitable versions of mercurial and hg-git (and python, I guess) and warn the user if necessary.\n\n\nAs for your complaints about not getting proper credit in the gitifyhg README etc.: I agree that it is very much lacking in this regard, and will work towards rectifying this (indeed, I already suggested this to the other gitifyhg devs).\n\nI'll also look into using sharness for gitifyhg test (which is based on the git test suite), as I also don't like the current test setup in gitifyhg, and indeed, the other gitifyhg devs agree. This would also make it easier to share and compare tests between remote-hg and gitifyhg if desired.\n\nI won't reply to all the other stuff you wrote, as it just causes too much bile to raise up re-reading it, and I am not sure I could manage to reply in an even remotely neutral tone. So I'll refrain from attempting, as I am not interested in a fight between the two projects, or anybody for that matter. Nor do I see this as a competition where the \"best\" wins -- if somebody prefers remote-hg over gitifyhg, or the other way around, I don't care much, as long as at least one of the tools satisfy their needs. \n\nRather, all *I* am interested is using git to access a couple hg repositories that I absolutely must access. And helping several friend and colleagues who are in the precise same situation. Well, Jed and me already explained why e.g. forced push makes remote-hg an absolute no-go for me and several other people. Whether you accept this or not is irrelevant -- it sadly won't change the reality I and others have to deal with at work and elsewhere.\n\n\nCheers,\nMax"},{"id":"213310","messageId":"CAMP44s10HGpfz=r1m8QRFY4V+rAOkiRaerW1T=vHz2YpbBH6Zg@mail.gmail.com","threadId":"33358","inReplyTo":"BA2657F2-708B-434E-87D2-D6371806E2D3@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-06T00:45:37Z","receivedAt":"2013-04-06T00:45:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 5, 2013 at 4:30 PM, Max Horn wrote:\n\n> On 04.04.2013, at 08:42, Felipe Contreras wrote:\n\n> Please consider that the willingness of people to collaborate with you in any way is directly related to how you treat them. That includes bug reports. The way you acted towards Jed, who was very calmly and matter-of-factly explaining things, was IMHO completely inappropriate and unacceptable\n\nHe did not provide any bug report at all, also, he was not willing to\ncollaborate, as he clearly stated; he won't work git-hg bridges no\nmore.\n\n> Indeed, I should augment my list of reasons why people might not want to contribute to remote-hg by one major bullet point: You. And please, don't feel to compelled to tell us that Junio is really the maintainer of remote-hg and not you: Whether this is true or not doesn't matter for this point.\n\nOh but it does. The only reason my remote-hg managed to land in the\nmainline is because I showed it was superior to the other\nremote-hg[1], and that there really was no point in trying to salvage\nthe other code base. Maybe this turns out to be a mistake, and the\nother remote-hg manages to improve and surpass my remote-hg, but it\nseems rather unlikely at this point.\n\nSimilarly, you could *show* that gitifyhg is superior than remote-hg,\nwhy it makes sense to use that instead of trying to improve this code\nbase, but you don't, because you can't, because it doesn't make sense.\n\nUltimately this is not about people, this is about the code. A\nsensible person that is not emotionally attached to any code, would\nsimply look at the code, and if what you claim is true (that remote-hg\nhas many issues), this sensible person would start cherry picking\npatches from gitifyhg, send them to the git mailing list explaining\nwhy they make sense. Eventually, remote-hg in git.git would become\nessentially gitifyhg (albeit better because it would have received\nmore review from other git developers). Codewise this would make\nsense.\n\nAnd this sensible person would replace me as the go-to person for\nremote-hg. And he would probably have a friendly and wonderful\npersonality, and you can accept him as your messiah and what not. But\nthis wouldn't change the fact that codewise this is the best way to\nproceed.\n\nBut the fact of the matter is that either a) remote-hg is perfectly\nfine, or b) this sensible person doesn't exist.\n\n>> , I find it\n>> annoying that you claim to know what is important for users, as if\n>> somehow knowing that gitifyhg doesn't work with the user's version of\n>> mercurial (e.g. 1.8) is better than remote-hg's situation; where it\n>> *actually works*, but it's not mentioned. Yeah, mentioning that it\n>> doesn't work is better than working, right.\n>\n> I'll leave it to everybody to read what you wrote there, and contrast it with the following, and draw their own conclusions...\n\nKeep in mind that it's not me the one that claims remote-hg is\nsuperior because it supports 1.8, as you seem try to portray. Rather,\nit's _you_ the one that claims superiority because gitifyhg *mentions*\nsupport until 1.9 (which remote-hg also supports).\n\nIt's not important who supports the most ancient version of mercurial\nthat nobody uses anyway, what is important is that *mentioning* or not\nmentioning which ancient version of mercurial is supported doesn't\nmake one project superior to the other.\n\nBut perhaps this point is too subtle for you to understand, so there:\nhttps://github.com/felipec/git/wiki/Git-remote-hg\n\nNow it's mentioned that remote-hg too, supports up to version 1.9. Can\nwe agree now, that nobody has any advantage, either on version\nsupport, or the mentioning of version support?\n\n> Indeed, util.url was only added in 1.9.3. OK, let's work around that. Then local clones work. But of course in reality, most users will want to interact with a remote repository. But that's still broken:\n\nFixed:\nhttps://github.com/felipec/git/commit/df0ed732b56c6c7910cc76f3e930229816e27117\n\nAnd it was _you_ the one that sent the commit that broke it to the git\nmailing list to be pushed.\n\n> Right, clone() changed. And some more stuff. See .\n\nIndeed, that might be useful, but that doesn't mean remote-hg doesn't\nwork with 1.8; it works perfectly fine for local repositories, and all\nthe tests pass.\n\n> There also was a good reason why I stopped at that point, but I don't remember the details right now. And quite frankly, I have zero incentive to even try to remember. But anyway, I don't think it's that useful to add support for 1.8, too, since one can't get back much further anyway. And upgrading to a newer Mercurial is (a) quite easy (even if you don't have root, just install it into $HOME), and (b) using a newer Mercurial version is a good idea for other reasons, too.\n\nIf supporting 1.8 is not useful because most people have newer\nversions, then mentioning support for 1.9 doesn't give any advantage.\nThanks for wasting our time on something nobody cares anyway.\n\n>>> BTW, I just pulled you hg-next branch, and run \"make test\" in that. The tests in test-hg-hg-git.sh actually all failed (with remote-hg). Do I need to do something special for those to work?\n>>\n>> No, they should just work. Perhaps you have an old version of hg-git\n>> (I have v0.4). You can check the errors with\n>> GIT_TEST_OPTS=\"--verbose\".\n>\n> Yup, that was it, thanks. It would be kinda nice if the test code could check for suitable versions of mercurial and hg-git (and python, I guess) and warn the user if necessary.\n\nYes, but how many people run these tests? And how many people have\nhg-git in the first place? And how many people care about\ntest-hg-hg-git? I'll guess not so many, so I'm not really looking\nforward to see what are the issues with older versions of hg-git.\n\n> As for your complaints about not getting proper credit in the gitifyhg README etc.: I agree that it is very much lacking in this regard, and will work towards rectifying this (indeed, I already suggested this to the other gitifyhg devs).\n\nThanks.\n\n> I'll also look into using sharness for gitifyhg test (which is based on the git test suite), as I also don't like the current test setup in gitifyhg, and indeed, the other gitifyhg devs agree. This would also make it easier to share and compare tests between remote-hg and gitifyhg if desired.\n\nThat would be really good.\n\n> Jed and me already explained why e.g. forced push makes remote-hg an absolute no-go for me and several other people.\n\n% git config remote-hg.force-push false\n\nProblem solved. You don't need to work on a another project to avoid this.\n\n> Whether you accept this or not is irrelevant -- it sadly won't change the reality I and others have to deal with at work and elsewhere.\n\nThe reality is you lack imagination. I've yet to see a single argument\nthat shows a problem with using a dedicated branch to push bookmarks.\n\n> I won't reply to all the other stuff you wrote, as it just causes too much bile to raise up re-reading it, and I am not sure I could manage to reply in an even remotely neutral tone. So I'll refrain from attempting, as I am not interested in a fight between the two projects, or anybody for that matter. Nor do I see this as a competition where the \"best\" wins -- if somebody prefers remote-hg over gitifyhg, or the other way around, I don't care much, as long as at least one of the tools satisfy their needs.\n>\n> Rather, all *I* am interested is using git to access a couple hg repositories that I absolutely must access. And helping several friend and colleagues who are in the precise same situation.\n\nSo you are unable to argue why is it that gitifyhg is necessary, or\ngood. I take this as evidence that you are too emotionally invested to\naccept the possibility that there's no good reason for the existence\nof gitifyhg.\n\ngitifyhg is not technically, or in any way, superior to remote-hg. You\nshould just give it up, and try to move as much code as possible to\nremote-hg (is there any that will be useful?), and perhaps maintain a\nbranch to make remote-hg behave as you want (I already provided an\nexample), but on top of remote-hg. You can have your own github repo,\nwith your own wiki, and your own releases as you have it now. Then it\nwould be easier to share code, and if gitifyhg turns out to be truly\nsuperior, it would be easier to simply merge those patches that enable\ngitifyhg behavior, which you claim make all the difference in the\nworld.\n\nIt would be great if we could all work together in remote-hg, but\ngiven the fact that at no point in time did you consider to \"fix\"\nremote-hg, and that you spend considerable amounts of time claiming\nthat gitifyhg is superior, specially in remote-hg's own bug tracker,\nrather than sending patches for remote-hg, which would prove your\npoint much more easily (if it was correct), I don't think you are\nallowing for that possibility.\n\nCheers.\n\n[1] https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg\n\n-- \nFelipe Contreras\n"},{"id":"213274","messageId":"7vd2u8bg7x.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"BA2657F2-708B-434E-87D2-D6371806E2D3@quendi.de","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-06T01:28:02Z","receivedAt":"2013-04-06T01:28:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn writes:\n\n> OK, I'll try to keep a professional tone from now on :-).\n>\n> Please consider that the willingness of people to collaborate with\n> you in any way is directly related to how you treat them. That\n> includes bug reports. The way you acted towards Jed, who was very\n> calmly and matter-of-factly explaining things, was IMHO completely\n> inappropriate and unacceptable. Indeed, I should augment my list\n> of reasons why people might not want to contribute to remote-hg by\n> one major bullet point: You. And please, don't feel to compelled\n> to tell us that Junio is really the maintainer of remote-hg and\n> not you: Whether this is true or not doesn't matter for this\n> point.\n\nOnly on this point, as the top-level maintainer. I do not have any\nopinion on technical merits between the two Hg gateways myself.\n\nA tool that is in contrib/ follows the contrib/README rule.\n\nI do not maintain it. Maintenance is up to the person who asked to\ninclude it there. I do ask the people who propose to add something\nin contrib/ to promise that they arrange it to be maintained.\n\nI do not even guarantee that they are the best in the breed in their\nrespective category. When something is added to contrib/, others can\nraise objections by proposing alternatives, by arguing that tools of\nthe nature are better kept out of my tree, etc. When remote-hg was\nadded, I didn't see specific objections against it.\n\nThere is one generic objection to adding anything new in contrib/ I\nhave myself, though.\n\nIn early days of Git, almost all users, who might be interested in\nimproving their Git experience by helping to polish third-party\ntools, had clones of my tree and did not hesitate to come to this\nlist. Back then, having a copy of an emerging third-party tool in my\ntree in contrib/ was a good way to give more exposure to it, and to\ngive those interested in it a place to meet and join forces to\nimprove it. Because Git population was small, almost everybody was\nhere, and it was an efficient distribution mechanism.\n\nGit is now reasonably well known and has big enough user base, and\nmany users, even those who are inclined to help improving their Git\nexperience by contributing to third-party tools, do not necessarily\nhave a clone of my tree. A third-party tool around Git, if it is\nany good, is likely to have much much better chance to thrive as a\nfree-standing project with its own community, compared to those\nearly days.\n"},{"id":"213311","messageId":"CAMP44s1t=cTQiOoXdbdEKa3zLa+8pi+BUU1n1XOzo+-LqGHs2Q@mail.gmail.com","threadId":"33358","inReplyTo":"7vd2u8bg7x.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-06T01:47:10Z","receivedAt":"2013-04-06T01:47:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 5, 2013 at 7:28 PM, Junio C Hamano wrote:\n\n> A tool that is in contrib/ follows the contrib/README rule.\n>\n> I do not maintain it. Maintenance is up to the person who asked to\n> include it there. I do ask the people who propose to add something\n> in contrib/ to promise that they arrange it to be maintained.\n\nThat's true, but I meant that you are the gatekeeper. Ultimately you\ndecide which patches go in. If Max, or anybody else, wants a patch\ninto contrib, you can get it in, even if I disagree with it. You can\nalso decide that somebody from gitifyhg might be a more suitable\nperson as a maintainer of remote-hg.\n\nEither way, I think if things go well, remote-hg will prove it's worth\nand move out of contrib and into git's core.\n\n-- \nFelipe Contreras\n"},{"id":"213316","messageId":"CDBF6E3BB68D4385B19C53A447186556@PhilipOakley","threadId":"33358","inReplyTo":"CAMP44s10HGpfz=r1m8QRFY4V+rAOkiRaerW1T=vHz2YpbBH6Zg@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-06T14:09:10Z","receivedAt":"2013-04-06T14:09:10Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Saturday, April 06, 2013 1:45 AM\n> On Fri, Apr 5, 2013 at 4:30 PM, Max Horn wrote:\n>\n>> On 04.04.2013, at 08:42, Felipe Contreras wrote:\n>\n>> Please consider [...]\n\n> Ultimately this is not about people, this is about the code.\n\nIn the case of helper functions this is not the case.\n\nThe question would be better framed:\n\"Does this, or that, helper function make users (people) feel helped, or \nfrustrated (or somewhere in limbo)?\".\n\nI've called IT help desks and often felt frustrated, and some times I've \ngot one of the good girls/guys who worked with me to improve my \nsituation (often despite official policies). I get back to those folks \n(even if they 'failed').\n\nIt's not a binary black/white issue when real users need help. It's no \ngood keeping with the faith (e.g. the Git ideal, the coders ideal, ..) \nwhen the users (a mixed group) environmental doctine differs.\n\n> A sensible person that is not emotionally attached to any code,\n [I'm thinking users here, they are emotionally attached to their \noriginal problem, and sense doesn't come into it]\n\n> would simply look at the code,\nUnfortunately, even for reasonable coders, looking at the code isn't \nusually the case because of lack of time, unfamiliarity with the code, \nextent of the code, availablity of the code (they may be simply running \na packaged/compiled 'app'), this is not that likely to happen. We should \nbe thankful when folk do look.\n\nIt's hard enough to get \"good\" bug reports from fellow coders (they are \nonly human / no more human than us) that tell us what _we_ want to know \n(rather than what _they_ remember, or was important to them). ;-)\n\n\nI don't use Hg, but as I read the discussion, there are \nincomaptibilities between Git, and Hg. Thus neither helper can ever be \nperfect. The winners will be those who solve a user need with enough \ndocumentation and error capture to make them (their user group) feel \nhappy. At the moment it looks like the discussion is stratifying into \nvarious \"it worked for me\" camps, each with their own problem children \nrepos that won't respond to parental advice, even with a --force from \nsocial services.\n\nPhilip\n[As they say back home: Between thee and me, ther's nowt so queer as \nfowk, and I ain't so sure about thee] \n"},{"id":"213314","messageId":"CAMP44s1_5wq6XSMZ64wRMcohLB_oA0s1VWqmJ1iBGnV_nCijXQ@mail.gmail.com","threadId":"33358","inReplyTo":"CDBF6E3BB68D4385B19C53A447186556@PhilipOakley","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-06T16:01:04Z","receivedAt":"2013-04-06T16:01:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Apr 6, 2013 at 8:09 AM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Saturday, April 06, 2013 1:45 AM\n\n>> Ultimately this is not about people, this is about the code.\n>\n>\n> In the case of helper functions this is not the case.\n>\n> The question would be better framed:\n> \"Does this, or that, helper function make users (people) feel helped, or\n> frustrated (or somewhere in limbo)?\".\n\nAnd that question is ultimately answered by code.\n\n> I've called IT help desks and often felt frustrated, and some times I've got\n> one of the good girls/guys who worked with me to improve my situation (often\n> despite official policies). I get back to those folks (even if they\n> 'failed').\n\nThat is not an issue when you don't have a situation that needs\nsupport, when everything just works. Having one issue with bad support\nis better than having 5 issues with good support.\n\n> It's not a binary black/white issue when real users need help. It's no good\n> keeping with the faith (e.g. the Git ideal, the coders ideal, ..) when the\n> users (a mixed group) environmental doctine differs.\n\nAnd neither Max or Jed are users, so this doesn't apply to them.\n\nAs for actual users, well show me, which remote-hg users have had bad support?\n\nhttps://github.com/felipec/git/issues\n\n>> A sensible person that is not emotionally attached to any code,\n>\n> [I'm thinking users here, they are emotionally attached to their original\n> problem, and sense doesn't come into it]\n\nThat's irrelevant, a sensible developer would maximize the amount of\nissues that do **not** hit the users.\n\n>> would simply look at the code,\n>\n> Unfortunately, even for reasonable coders, looking at the code isn't usually\n> the case because of lack of time, unfamiliarity with the code, extent of the\n> code, availablity of the code (they may be simply running a\n> packaged/compiled 'app'), this is not that likely to happen. We should be\n> thankful when folk do look.\n\nIf this sensible developer doesn't have time to look at remote-hg\ncode, he has less time to make a possibly inferior alternative work on\npar or better. Thus a sensible developer would either look at\nremote-hg code, or do not develop.\n\n> It's hard enough to get \"good\" bug reports from fellow coders (they are only\n> human / no more human than us) that tell us what _we_ want to know (rather\n> than what _they_ remember, or was important to them). ;-)\n\nNobody is asking for that.\n\n> I don't use Hg, but as I read the discussion, there are incomaptibilities\n> between Git, and Hg. Thus neither helper can ever be perfect. The winners\n> will be those who solve a user need with enough documentation and error\n> capture to make them (their user group) feel happy. At the moment it looks\n> like the discussion is stratifying into various \"it worked for me\" camps,\n> each with their own problem children repos that won't respond to parental\n> advice, even with a --force from social services.\n\nI don't think so. The discussion has been about hypothetical, not real\nusers. The one person that did claim was hit by a bug, had no evidence\nfor it nor cared, so it hardly matters. The rest is in pondering such\nas if the user does this and that, and somebody else in the team does\nthat, and then the user does this, and the team has that policy, they\nmight end in a bit of a kerfuffle. Not something that has _actually_\nhappened.\n\nAnd I'm confident that with time it will be shown that in terms of\nreal issues, remote-hg would have less, and be fixed faster.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"213373","messageId":"7vy5cv818k.fsf@alter.siamese.dyndns.org","threadId":"33358","inReplyTo":"CAMP44s1t=cTQiOoXdbdEKa3zLa+8pi+BUU1n1XOzo+-LqGHs2Q@mail.gmail.com","subject":"Re: [PATCH 00/13] remote-hg: general updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-07T03:32:11Z","receivedAt":"2013-04-07T03:32:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Fri, Apr 5, 2013 at 7:28 PM, Junio C Hamano wrote:\n>\n>> A tool that is in contrib/ follows the contrib/README rule.\n>>\n>> I do not maintain it. Maintenance is up to the person who asked to\n>> include it there. I do ask the people who propose to add something\n>> in contrib/ to promise that they arrange it to be maintained.\n>\n> That's true, but I meant that you are the gatekeeper. Ultimately you\n> decide which patches go in. If Max, or anybody else, wants a patch\n> into contrib, you can get it in, even if I disagree with it.\n\nIn an ideal fantasy world, it could be true, but when I say \"I do\nnot maintain it, and people who put it in contrib/ is responsible\nfor it\", I really mean it.\n\nI may find the behaviour/performance of the sub-maintainer of a part\nin contrib/ unsatisfactory and have to take an administrative action\n(e.g. to remove the problematic part out of contrib/), but I would\nrather not to do that kind of thing, if possible. Instead I expect\npeople who have any code in my tree (even in contrib/) to act as a\nresponsible adult, taking and responding to constructive criticisms\nwell, and more importantly, nudging those whose utterance you find\nare mostly noise into raising a more concrete and actionable issues\nthat would be useful to you as an input.\n\n> Either way, I think if things go well, remote-hg will prove it's worth\n> and move out of contrib and into git's core.\n\nThat was what you promised when we started carrying it in contrib/;\nI am still hoping to see it happen when it matures.\n"}]}