{"thread":{"id":"31960","subject":"[PATCH v4 03/13] remote-hg: add support for pushing","startedAt":"2012-10-28T03:54:00Z","lastAt":"2012-11-05T16:15:06Z","messageCount":75,"participants":["Felipe Contreras","Jeff King","Johannes Schindelin","Michael J Gruber","Jonathan Nieder","Daniel Barkalow","Junio C Hamano","René Scharfe","Tomas Carnecky","Martin Langhoff","Andreas Ericsson","Thomas Adam"],"isPatch":true,"patchVersion":4,"patchTotal":13},"messages":[{"id":"202019","messageId":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":null,"subject":"[PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:00Z","receivedAt":"2012-10-28T03:54:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI've ported the tests from hg-git and made sure that the output from remote-hg\nmatches the output of hg-git. With these extensive tests I would consider this\none ready for wide use. Not only do the tests pass, I've compared the generated\nrepos of a few projects, and the SHA-1's are exactly the same :)\n\nThis remote-hg has advantages other tools don't have:\n\n * Uses transport-helper (git clone hg::path)\n * The code is small\n * The code is simple\n * No external dependencies (other than mercurial)\n * It's easy to install (put into your path)\n * Has extensive tests\n * Active development\n * Has compatibility with hg-git\n * The required patches are available\n * No changes necesary to git core\n\nOne important alternative is the one written by Sverre Rabbelier that is now\nmaintained and distributed in msysgit. It's hard to evaluate this option as\nthere isn't a branch specific to this remote helper so it would be possible to\nevaluate the necessary patches.\n\nChanges since v3:\n\n * New extensive tests\n * Add compatibility mode with hg-git\n * Added support for boomkars\n * Add mercurial information to the git msg (branch, renames, extra, etc.)\n * Properly handle HEAD\n * Fix author/committer information\n * Implement 'done' feature for error handling\n * Restore hg user properly\n * Set file correct modes\n * Match hg merge behavior\n * Prefix hg branches\n * Encoding fixes\n * Stricter parser\n * Support for 'reset' command\n * Fix support for URL pushing (unaliased)\n\nChanges since v2:\n\n * Added support for pushing\n * Tests copied from original remote-hg\n * Custom default -> master renames removed\n * Code reorganized\n\nChanges since v1:\n\n * Improved documentation\n * Use more common 'python' binary\n * Warn, don't barf when a branch has multiple heads\n * Fixed marks to fetch after cloned\n * Support for cloning/pulling remote repositories\n * Use a more appropriate internal directory (e.g. .git/hg/origin)\n * Fixes for python3\n\nFelipe Contreras (13):\n Add new remote-hg transport helper\n remote-hg: add support for bookmarks\n remote-hg: add support for pushing\n remote-hg: add support for remote pushing\n remote-hg: add support to push URLs\n remote-hg: make sure the encoding is correct\n remote-hg: match hg merge behavior\n remote-hg: add support for hg-git compat mode\n remote-hg: add compat for hg-git author fixes\n remote-hg: fake bookmark when there's none\n remote-hg: add support for fake remote\n remote-hg: add tests to compare with hg-git\n remote-hg: add extra author test\n\n contrib/remote-hg/git-remote-hg | 770 ++++++++++++++++++++++++++++++++++++++++\n t/t5802-remote-hg-hg-git.sh | 449 +++++++++++++++++++++++\n 2 files changed, 1219 insertions(+)\n create mode 100755 contrib/remote-hg/git-remote-hg\n create mode 100755 t/t5802-remote-hg-hg-git.sh\n\n-- \n1.8.0\n"},{"id":"202018","messageId":"1351396453-29042-2-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 01/13] Add new remote-hg transport helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:01Z","receivedAt":"2012-10-28T03:54: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-hg/git-remote-hg | 356 ++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 356 insertions(+)\n create mode 100755 contrib/remote-hg/git-remote-hg\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nnew file mode 100755\nindex 0000000..c771182\n--- /dev/null\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -0,0 +1,356 @@\n+#!/usr/bin/python\n+\n+# Inspired by Rocco Rutte's hg-fast-export\n+\n+# Just copy to your ~/bin, or anywhere in your $PATH.\n+# Then you can clone with:\n+# git clone hg::/path/to/mercurial/repo/\n+\n+from mercurial import hg, ui\n+\n+import re\n+import sys\n+import os\n+import json\n+\n+NAME_RE = re.compile('^([^<>]+)')\n+AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]+)>$')\n+\n+def die(msg, *args):\n+ sys.stderr.write('ERROR: %s\\n' % (msg % args))\n+ sys.exit(1)\n+\n+def warn(msg, *args):\n+ sys.stderr.write('WARNING: %s\\n' % (msg % args))\n+\n+def gitmode(flags):\n+ return 'l' in flags and '120000' or 'x' in flags and '100755' or '100644'\n+\n+def gittz(tz):\n+ return '%+03d%02d' % (-tz / 3600, -tz % 3600 / 60)\n+\n+class Marks:\n+\n+ def __init__(self, path):\n+ self.path = path\n+ self.tips = {}\n+ self.marks = {}\n+ self.last_mark = 0\n+\n+ self.load()\n+\n+ def load(self):\n+ if not os.path.exists(self.path):\n+ return\n+\n+ tmp = json.load(open(self.path))\n+\n+ self.tips = tmp['tips']\n+ self.marks = tmp['marks']\n+ self.last_mark = tmp['last-mark']\n+\n+ def dict(self):\n+ return { 'tips': self.tips, 'marks': self.marks, 'last-mark' : self.last_mark }\n+\n+ def store(self):\n+ json.dump(self.dict(), open(self.path, 'w'))\n+\n+ def __str__(self):\n+ return str(self.dict())\n+\n+ def from_rev(self, rev):\n+ return self.marks[str(rev)]\n+\n+ def next_mark(self, rev):\n+ self.last_mark += 1\n+ self.marks[str(rev)] = self.last_mark\n+ return self.last_mark\n+\n+ def is_marked(self, rev):\n+ return self.marks.has_key(str(rev))\n+\n+ def get_tip(self, branch):\n+ return self.tips.get(branch, 0)\n+\n+ def set_tip(self, branch, tip):\n+ self.tips[branch] = tip\n+\n+class Parser:\n+\n+ def __init__(self, repo):\n+ self.repo = repo\n+ self.line = self.get_line()\n+\n+ def get_line(self):\n+ return sys.stdin.readline().strip()\n+\n+ def __getitem__(self, i):\n+ return self.line.split()[i]\n+\n+ def check(self, word):\n+ return self.line.startswith(word)\n+\n+ def each_block(self, separator):\n+ while self.line != separator:\n+ yield self.line\n+ self.line = self.get_line()\n+\n+ def __iter__(self):\n+ return self.each_block('')\n+\n+ def next(self):\n+ self.line = self.get_line()\n+ if self.line == 'done':\n+ self.line = None\n+\n+def export_file(fc):\n+ d = fc.data()\n+ print \"M %s inline %s\" % (gitmode(fc.flags()), fc.path())\n+ print \"data %d\" % len(d)\n+ print d\n+\n+def get_filechanges(repo, ctx, parents):\n+ l = [repo.status(p, ctx)[:3] for p in parents]\n+ changed, added, removed = [set(sum(e, [])) for e in zip(*l)]\n+ return added | changed, removed\n+\n+def fixup_user(user):\n+ user = user.replace('\"', '')\n+ name = mail = None\n+ m = AUTHOR_RE.match(user)\n+ if m:\n+ name = m.group(1)\n+ mail = m.group(2).strip()\n+ else:\n+ m = NAME_RE.match(user)\n+ if m:\n+ name = m.group(1).strip()\n+\n+ if not name:\n+ name = 'Unknown'\n+ if not mail:\n+ mail = 'unknown'\n+\n+ return '%s <%s>' % (name, mail)\n+\n+def get_repo(url, alias):\n+ global dirname\n+\n+ myui = ui.ui()\n+ myui.setconfig('ui', 'interactive', 'off')\n+\n+ if hg.islocal(url):\n+ repo = hg.repository(myui, url)\n+ else:\n+ local_path = os.path.join(dirname, 'clone')\n+ if not os.path.exists(local_path):\n+ peer, dstpeer = hg.clone(myui, {}, url, local_path, update=False, pull=True)\n+ repo = dstpeer.local()\n+ else:\n+ repo = hg.repository(myui, local_path)\n+ peer = hg.peer(myui, {}, url)\n+ repo.pull(peer, heads=None, force=True)\n+\n+ return repo\n+\n+def rev_to_mark(rev):\n+ global marks\n+ return marks.from_rev(rev)\n+\n+def export_ref(repo, name, kind, head):\n+ global prefix, marks\n+\n+ ename = '%s/%s' % (kind, name)\n+ tip = marks.get_tip(ename)\n+\n+ # mercurial takes too much time checking this\n+ if tip and tip == head.rev():\n+ # nothing to do\n+ return\n+ revs = repo.revs('%u:%u' % (tip, head))\n+ count = 0\n+\n+ revs = [rev for rev in revs if not marks.is_marked(rev)]\n+\n+ for rev in revs:\n+\n+ c = repo[rev]\n+ (manifest, user, (time, tz), files, desc, extra) = repo.changelog.read(c.node())\n+ rev_branch = extra['branch']\n+\n+ author = \"%s %d %s\" % (fixup_user(user), time, gittz(tz))\n+ if 'committer' in extra:\n+ user, time, tz = extra['committer'].rsplit(' ', 2)\n+ committer = \"%s %s %s\" % (user, time, gittz(int(tz)))\n+ else:\n+ committer = author\n+\n+ parents = [p for p in repo.changelog.parentrevs(rev) if p >= 0]\n+\n+ if len(parents) == 0:\n+ modified = c.manifest().keys()\n+ removed = []\n+ else:\n+ modified, removed = get_filechanges(repo, c, parents)\n+\n+ if len(parents) == 0 and rev:\n+ print 'reset %s/%s' % (prefix, ename)\n+\n+ print \"commit %s/%s\" % (prefix, ename)\n+ print \"mark :%d\" % (marks.next_mark(rev))\n+ print \"author %s\" % (author)\n+ print \"committer %s\" % (committer)\n+ print \"data %d\" % (len(desc))\n+ print desc\n+\n+ if len(parents) > 0:\n+ print \"from :%s\" % (rev_to_mark(parents[0]))\n+ if len(parents) > 1:\n+ print \"merge :%s\" % (rev_to_mark(parents[1]))\n+\n+ for f in removed:\n+ print \"D %s\" % (f)\n+ for f in modified:\n+ export_file(c.filectx(f))\n+ print\n+\n+ count += 1\n+ if (count % 100 == 0):\n+ print \"progress revision %d '%s' (%d/%d)\" % (rev, ename, count, len(revs))\n+ print \"#############################################################\"\n+\n+ # make sure the ref is updated\n+ print \"reset %s/%s\" % (prefix, ename)\n+ print \"from :%u\" % rev_to_mark(rev)\n+ print\n+\n+ marks.set_tip(ename, rev)\n+\n+def export_tag(repo, tag):\n+ export_ref(repo, tag, 'tags', repo[tag])\n+\n+def export_branch(repo, branch):\n+ tip = get_branch_tip(repo, branch)\n+ head = repo[tip]\n+ export_ref(repo, branch, 'branches', head)\n+\n+def export_head(repo):\n+ global g_head\n+ export_ref(repo, g_head[0], g_head[1], g_head[2])\n+\n+def do_capabilities(parser):\n+ global prefix, dirname\n+\n+ print \"import\"\n+ print \"refspec refs/heads/branches/*:%s/branches/*\" % prefix\n+ print \"refspec refs/tags/*:%s/tags/*\" % prefix\n+ print\n+\n+def get_branch_tip(repo, branch):\n+ global branches\n+\n+ heads = branches.get(branch, None)\n+ if not heads:\n+ return None\n+\n+ # verify there's only one head\n+ if (len(heads) > 1):\n+ warn(\"Branch '%s' has more than one head, consider merging\" % branch)\n+ return repo.branchtip(branch)\n+\n+ return heads[0]\n+\n+def list_branch_head(repo, cur):\n+ global g_head\n+\n+ tip = get_branch_tip(repo, cur)\n+ head = 'branches/' + cur\n+ print \"@refs/heads/%s HEAD\" % head\n+ g_head = (head, 'branches', repo[tip])\n+\n+def do_list(parser):\n+ global branches\n+\n+ repo = parser.repo\n+ for branch in repo.branchmap():\n+ heads = repo.branchheads(branch)\n+ if len(heads):\n+ branches[branch] = heads\n+\n+ cur = repo.dirstate.branch()\n+\n+ list_branch_head(repo, cur)\n+ for branch in branches:\n+ print \"? refs/heads/branches/%s\" % branch\n+\n+ for tag, node in repo.tagslist():\n+ if tag == 'tip':\n+ continue\n+ print \"? refs/tags/%s\" % tag\n+\n+ print\n+\n+def do_import(parser):\n+ repo = parser.repo\n+\n+ path = os.path.join(dirname, 'marks-git')\n+\n+ print \"feature done\"\n+ if os.path.exists(path):\n+ print \"feature import-marks=%s\" % path\n+ print \"feature export-marks=%s\" % path\n+ sys.stdout.flush()\n+\n+ # lets get all the import lines\n+ while parser.check('import'):\n+ ref = parser[1]\n+\n+ if (ref == 'HEAD'):\n+ export_head(repo)\n+ elif ref.startswith('refs/heads/branches/'):\n+ branch = ref[len('refs/heads/branches/'):]\n+ export_branch(repo, branch)\n+ elif ref.startswith('refs/tags/'):\n+ tag = ref[len('refs/tags/'):]\n+ export_tag(repo, tag)\n+\n+ parser.next()\n+\n+ print 'done'\n+\n+def main(args):\n+ global prefix, dirname, marks, branches\n+\n+ alias = args[1]\n+ url = args[2]\n+\n+ gitdir = os.environ['GIT_DIR']\n+ dirname = os.path.join(gitdir, 'hg', alias)\n+ branches = {}\n+\n+ repo = get_repo(url, alias)\n+ prefix = 'refs/hg/%s' % alias\n+\n+ if not os.path.exists(dirname):\n+ os.makedirs(dirname)\n+\n+ marks_path = os.path.join(dirname, 'marks-hg')\n+ marks = Marks(marks_path)\n+\n+ parser = Parser(repo)\n+ for line in parser:\n+ if parser.check('capabilities'):\n+ do_capabilities(parser)\n+ elif parser.check('list'):\n+ do_list(parser)\n+ elif parser.check('import'):\n+ do_import(parser)\n+ elif parser.check('export'):\n+ do_export(parser)\n+ else:\n+ die('unhandled command: %s' % line)\n+ sys.stdout.flush()\n+\n+ marks.store()\n+\n+sys.exit(main(sys.argv))\n-- \n1.8.0\n"},{"id":"202020","messageId":"1351396453-29042-3-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 02/13] remote-hg: add support for bookmarks","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:02Z","receivedAt":"2012-10-28T03:54: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-hg/git-remote-hg | 20 +++++++++++++++++---\n 1 file changed, 17 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex c771182..4ba9ee6 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -6,7 +6,7 @@\n # Then you can clone with:\n # git clone hg::/path/to/mercurial/repo/\n \n-from mercurial import hg, ui\n+from mercurial import hg, ui, bookmarks\n \n import re\n import sys\n@@ -229,6 +229,10 @@ def export_ref(repo, name, kind, head):\n def export_tag(repo, tag):\n export_ref(repo, tag, 'tags', repo[tag])\n \n+def export_bookmark(repo, bmark):\n+ head = bmarks[bmark]\n+ export_ref(repo, bmark, 'bookmarks', head)\n+\n def export_branch(repo, branch):\n tip = get_branch_tip(repo, branch)\n head = repo[tip]\n@@ -243,6 +247,7 @@ def do_capabilities(parser):\n \n print \"import\"\n print \"refspec refs/heads/branches/*:%s/branches/*\" % prefix\n+ print \"refspec refs/heads/*:%s/bookmarks/*\" % prefix\n print \"refspec refs/tags/*:%s/tags/*\" % prefix\n print\n \n@@ -269,7 +274,7 @@ def list_branch_head(repo, cur):\n g_head = (head, 'branches', repo[tip])\n \n def do_list(parser):\n- global branches\n+ global branches, bmarks\n \n repo = parser.repo\n for branch in repo.branchmap():\n@@ -277,11 +282,16 @@ def do_list(parser):\n if len(heads):\n branches[branch] = heads\n \n+ for bmark, node in bookmarks.listbookmarks(repo).iteritems():\n+ bmarks[bmark] = repo[node]\n+\n cur = repo.dirstate.branch()\n \n list_branch_head(repo, cur)\n for branch in branches:\n print \"? refs/heads/branches/%s\" % branch\n+ for bmark in bmarks:\n+ print \"? refs/heads/%s\" % bmark\n \n for tag, node in repo.tagslist():\n if tag == 'tip':\n@@ -310,6 +320,9 @@ def do_import(parser):\n elif ref.startswith('refs/heads/branches/'):\n branch = ref[len('refs/heads/branches/'):]\n export_branch(repo, branch)\n+ elif ref.startswith('refs/heads/'):\n+ bmark = ref[len('refs/heads/'):]\n+ export_bookmark(repo, bmark)\n elif ref.startswith('refs/tags/'):\n tag = ref[len('refs/tags/'):]\n export_tag(repo, tag)\n@@ -319,7 +332,7 @@ def do_import(parser):\n print 'done'\n \n def main(args):\n- global prefix, dirname, marks, branches\n+ global prefix, dirname, marks, branches, bmarks\n \n alias = args[1]\n url = args[2]\n@@ -327,6 +340,7 @@ def main(args):\n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'hg', alias)\n branches = {}\n+ bmarks = {}\n \n repo = get_repo(url, alias)\n prefix = 'refs/hg/%s' % alias\n-- \n1.8.0\n"},{"id":"202017","messageId":"1351396453-29042-4-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 03/13] remote-hg: add support for pushing","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:03Z","receivedAt":"2012-10-28T03:54:03Z","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-hg/git-remote-hg | 215 +++++++++++++++++++++++++++++++++++++++-\n 1 file changed, 213 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 4ba9ee6..4021a7d 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -6,7 +6,7 @@\n # Then you can clone with:\n # git clone hg::/path/to/mercurial/repo/\n \n-from mercurial import hg, ui, bookmarks\n+from mercurial import hg, ui, bookmarks, context\n \n import re\n import sys\n@@ -15,6 +15,7 @@ import json\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]+)>$')\n+RAW_AUTHOR_RE = re.compile('^(\\w+) (?:(.+)? )?<(.+)> (\\d+) ([+-]\\d+)')\n \n def die(msg, *args):\n sys.stderr.write('ERROR: %s\\n' % (msg % args))\n@@ -29,12 +30,17 @@ def gitmode(flags):\n def gittz(tz):\n return '%+03d%02d' % (-tz / 3600, -tz % 3600 / 60)\n \n+def hgmode(mode):\n+ m = { '0100755': 'x', '0120000': 'l' }\n+ return m.get(mode, '')\n+\n class Marks:\n \n def __init__(self, path):\n self.path = path\n self.tips = {}\n self.marks = {}\n+ self.rev_marks = {}\n self.last_mark = 0\n \n self.load()\n@@ -49,6 +55,9 @@ class Marks:\n self.marks = tmp['marks']\n self.last_mark = tmp['last-mark']\n \n+ for rev, mark in self.marks.iteritems():\n+ self.rev_marks[mark] = int(rev)\n+\n def dict(self):\n return { 'tips': self.tips, 'marks': self.marks, 'last-mark' : self.last_mark }\n \n@@ -61,11 +70,19 @@ class Marks:\n def from_rev(self, rev):\n return self.marks[str(rev)]\n \n+ def to_rev(self, mark):\n+ return self.rev_marks[mark]\n+\n def next_mark(self, rev):\n self.last_mark += 1\n self.marks[str(rev)] = self.last_mark\n return self.last_mark\n \n+ def new_mark(self, rev, mark):\n+ self.marks[str(rev)] = mark\n+ self.rev_marks[mark] = rev\n+ self.last_mark = mark\n+\n def is_marked(self, rev):\n return self.marks.has_key(str(rev))\n \n@@ -103,6 +120,35 @@ class Parser:\n if self.line == 'done':\n self.line = None\n \n+ def get_mark(self):\n+ i = self.line.index(':') + 1\n+ return int(self.line[i:])\n+\n+ def get_data(self):\n+ if not self.check('data'):\n+ return None\n+ i = self.line.index(' ') + 1\n+ size = int(self.line[i:])\n+ return sys.stdin.read(size)\n+\n+ def get_author(self):\n+ m = RAW_AUTHOR_RE.match(self.line)\n+ if not m:\n+ return None\n+ _, name, email, date, tz = m.groups()\n+\n+ if email != 'unknown':\n+ if name:\n+ user = '%s <%s>' % (name, email)\n+ else:\n+ user = '<%s>' % (email)\n+ else:\n+ user = name\n+\n+ tz = int(tz)\n+ tz = ((tz / 100) * 3600) + ((tz % 100) * 60)\n+ return (user, int(date), -tz)\n+\n def export_file(fc):\n d = fc.data()\n print \"M %s inline %s\" % (gitmode(fc.flags()), fc.path())\n@@ -157,6 +203,10 @@ def rev_to_mark(rev):\n global marks\n return marks.from_rev(rev)\n \n+def mark_to_rev(mark):\n+ global marks\n+ return marks.to_rev(mark)\n+\n def export_ref(repo, name, kind, head):\n global prefix, marks\n \n@@ -246,9 +296,17 @@ def do_capabilities(parser):\n global prefix, dirname\n \n print \"import\"\n+ print \"export\"\n print \"refspec refs/heads/branches/*:%s/branches/*\" % prefix\n print \"refspec refs/heads/*:%s/bookmarks/*\" % prefix\n print \"refspec refs/tags/*:%s/tags/*\" % prefix\n+\n+ path = os.path.join(dirname, 'marks-git')\n+\n+ if os.path.exists(path):\n+ print \"*import-marks %s\" % path\n+ print \"*export-marks %s\" % path\n+\n print\n \n def get_branch_tip(repo, branch):\n@@ -331,8 +389,159 @@ def do_import(parser):\n \n print 'done'\n \n+def parse_blob(parser):\n+ global blob_marks\n+\n+ parser.next()\n+ mark = parser.get_mark()\n+ parser.next()\n+ data = parser.get_data()\n+ blob_marks[mark] = data\n+ parser.next()\n+ return\n+\n+def parse_commit(parser):\n+ global marks, blob_marks, bmarks, parsed_refs\n+\n+ from_mark = merge_mark = None\n+\n+ a = parser.line.split(' ')\n+ ref = a[1]\n+ parser.next()\n+\n+ commit_mark = parser.get_mark()\n+ parser.next()\n+ author = parser.get_author()\n+ parser.next()\n+ committer = parser.get_author()\n+ parser.next()\n+ data = parser.get_data()\n+ parser.next()\n+ if parser.check('from'):\n+ from_mark = parser.get_mark()\n+ parser.next()\n+ if parser.check('merge'):\n+ merge_mark = parser.get_mark()\n+ parser.next()\n+ if parser.check('merge'):\n+ die('octopus merges are not supported yet')\n+\n+ files = {}\n+\n+ for line in parser:\n+ if parser.check('M'):\n+ t, m, mark_ref, path = line.split(' ')\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+ f = { 'deleted' : True }\n+ else:\n+ die('Unknown file command: %s' % line)\n+ files[path] = f\n+\n+ def getfilectx(repo, memctx, f):\n+ of = files[f]\n+ if 'deleted' in of:\n+ raise IOError\n+ is_exec = of['mode'] == 'x'\n+ is_link = of['mode'] == 'l'\n+ return context.memfilectx(f, of['data'], is_link, is_exec, None)\n+\n+ repo = parser.repo\n+\n+ user, date, tz = author\n+ extra = {}\n+\n+ if committer != author:\n+ extra['committer'] = \"%s %u %u\" % committer\n+\n+ if from_mark:\n+ p1 = repo.changelog.node(mark_to_rev(from_mark))\n+ else:\n+ p1 = '\\0' * 20\n+\n+ if merge_mark:\n+ p2 = repo.changelog.node(mark_to_rev(merge_mark))\n+ else:\n+ p2 = '\\0' * 20\n+\n+ ctx = context.memctx(repo, (p1, p2), data,\n+ files.keys(), getfilectx,\n+ user, (date, tz), extra)\n+\n+ node = repo.commitctx(ctx)\n+\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+ a = parser.line.split(' ')\n+ ref = a[1]\n+ parser.next()\n+ # ugh\n+ if parser.check('commit'):\n+ parse_commit(parser)\n+ return\n+ if not parser.check('from'):\n+ return\n+ from_mark = parser.get_mark()\n+ parser.next()\n+\n+ node = parser.repo.changelog.node(mark_to_rev(from_mark))\n+ parsed_refs[ref] = node\n+\n+def parse_tag(parser):\n+ a = parser.line.split(' ')\n+ name = a[1]\n+ parser.next()\n+ from_mark = parser.get_mark()\n+ parser.next()\n+ tagger = parser.get_author()\n+ parser.next()\n+ data = parser.get_data()\n+ parser.next()\n+\n+ # nothing to do\n+\n+def do_export(parser):\n+ global parsed_refs\n+\n+ parser.next()\n+\n+ for line in parser.each_block('done'):\n+ if parser.check('blob'):\n+ parse_blob(parser)\n+ elif parser.check('commit'):\n+ parse_commit(parser)\n+ elif parser.check('reset'):\n+ parse_reset(parser)\n+ elif parser.check('tag'):\n+ parse_tag(parser)\n+ elif parser.check('feature'):\n+ pass\n+ else:\n+ die('unhandled export command: %s' % line)\n+\n+ for ref, node in parsed_refs.iteritems():\n+ if ref.startswith('refs/heads/branches'):\n+ pass\n+ elif ref.startswith('refs/heads/'):\n+ bmark = ref[len('refs/heads/'):]\n+ bookmarks.pushbookmark(parser.repo, bmark, '', node)\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+\n+ print\n+\n def main(args):\n- global prefix, dirname, marks, branches, bmarks\n+ global prefix, dirname, branches, bmarks\n+ global marks, blob_marks, parsed_refs\n \n alias = args[1]\n url = args[2]\n@@ -341,6 +550,8 @@ def main(args):\n dirname = os.path.join(gitdir, 'hg', alias)\n branches = {}\n bmarks = {}\n+ blob_marks = {}\n+ parsed_refs = {}\n \n repo = get_repo(url, alias)\n prefix = 'refs/hg/%s' % alias\n-- \n1.8.0\n"},{"id":"202021","messageId":"1351396453-29042-5-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 04/13] remote-hg: add support for remote pushing","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:04Z","receivedAt":"2012-10-28T03:54:04Z","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-hg/git-remote-hg | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 4021a7d..b10e7d1 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -180,7 +180,7 @@ def fixup_user(user):\n return '%s <%s>' % (name, mail)\n \n def get_repo(url, alias):\n- global dirname\n+ global dirname, peer\n \n myui = ui.ui()\n myui.setconfig('ui', 'interactive', 'off')\n@@ -508,7 +508,7 @@ def parse_tag(parser):\n # nothing to do\n \n def do_export(parser):\n- global parsed_refs\n+ global parsed_refs, peer\n \n parser.next()\n \n@@ -539,12 +539,17 @@ def do_export(parser):\n \n print\n \n+ if peer:\n+ parser.repo.push(peer, force=False)\n+\n def main(args):\n global prefix, dirname, branches, bmarks\n global marks, blob_marks, parsed_refs\n+ global peer\n \n alias = args[1]\n url = args[2]\n+ peer = None\n \n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'hg', alias)\n-- \n1.8.0\n"},{"id":"202022","messageId":"1351396453-29042-6-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 05/13] remote-hg: add support to push URLs","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:05Z","receivedAt":"2012-10-28T03:54:05Z","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-hg/git-remote-hg | 14 ++++++++++++--\n 1 file changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex b10e7d1..c96e1a8 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -6,12 +6,13 @@\n # Then you can clone with:\n # git clone hg::/path/to/mercurial/repo/\n \n-from mercurial import hg, ui, bookmarks, context\n+from mercurial import hg, ui, bookmarks, context, util\n \n import re\n import sys\n import os\n import json\n+import shutil\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]+)>$')\n@@ -551,6 +552,12 @@ def main(args):\n url = args[2]\n peer = None\n \n+ if alias[4:] == url:\n+ is_tmp = True\n+ alias = util.sha1(alias).hexdigest()\n+ else:\n+ is_tmp = False\n+\n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'hg', alias)\n branches = {}\n@@ -581,6 +588,9 @@ def main(args):\n die('unhandled command: %s' % line)\n sys.stdout.flush()\n \n- marks.store()\n+ if not is_tmp:\n+ marks.store()\n+ else:\n+ shutil.rmtree(dirname)\n \n sys.exit(main(sys.argv))\n-- \n1.8.0\n"},{"id":"202023","messageId":"1351396453-29042-7-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 06/13] remote-hg: make sure the encoding is correct","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:06Z","receivedAt":"2012-10-28T03:54:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Independently of the environment.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-hg/git-remote-hg | 12 +++++++++++-\n 1 file changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex c96e1a8..1689573 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -6,7 +6,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\n+from mercurial import hg, ui, bookmarks, context, util, encoding\n \n import re\n import sys\n@@ -370,6 +370,9 @@ def do_import(parser):\n print \"feature export-marks=%s\" % path\n sys.stdout.flush()\n \n+ tmp = encoding.encoding\n+ encoding.encoding = 'utf-8'\n+\n # lets get all the import lines\n while parser.check('import'):\n ref = parser[1]\n@@ -388,6 +391,8 @@ def do_import(parser):\n \n parser.next()\n \n+ encoding.encoding = tmp\n+\n print 'done'\n \n def parse_blob(parser):\n@@ -471,8 +476,13 @@ def parse_commit(parser):\n files.keys(), getfilectx,\n user, (date, tz), extra)\n \n+ tmp = encoding.encoding\n+ encoding.encoding = 'utf-8'\n+\n node = repo.commitctx(ctx)\n \n+ encoding.encoding = tmp\n+\n rev = repo[node].rev()\n \n parsed_refs[ref] = node\n-- \n1.8.0\n"},{"id":"202024","messageId":"1351396453-29042-8-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 07/13] remote-hg: match hg merge behavior","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:07Z","receivedAt":"2012-10-28T03:54:07Z","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-hg/git-remote-hg | 15 +++++++++++++++\n 1 file changed, 15 insertions(+)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 1689573..57e54c2 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -406,6 +406,12 @@ def parse_blob(parser):\n parser.next()\n return\n \n+def get_merge_files(repo, p1, p2, files):\n+ for e in repo[p1].files():\n+ if e not in files:\n+ f = { 'ctx' : repo[p1][e] }\n+ files[e] = f\n+\n def parse_commit(parser):\n global marks, blob_marks, bmarks, parsed_refs\n \n@@ -450,6 +456,8 @@ def parse_commit(parser):\n of = files[f]\n if 'deleted' in of:\n raise IOError\n+ if 'ctx' in of:\n+ return of['ctx']\n is_exec = of['mode'] == 'x'\n is_link = of['mode'] == 'l'\n return context.memfilectx(f, of['data'], is_link, is_exec, None)\n@@ -472,6 +480,13 @@ def parse_commit(parser):\n else:\n p2 = '\\0' * 20\n \n+ #\n+ # If files changed from any of the parents, hg wants to know, but in git if\n+ # nothing changed from the first parent, nothing changed.\n+ #\n+ if merge_mark:\n+ get_merge_files(repo, p1, p2, files)\n+\n ctx = context.memctx(repo, (p1, p2), data,\n files.keys(), getfilectx,\n user, (date, tz), extra)\n-- \n1.8.0\n"},{"id":"202026","messageId":"1351396453-29042-9-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 08/13] remote-hg: add support for hg-git compat mode","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:08Z","receivedAt":"2012-10-28T03:54:08Z","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-hg/git-remote-hg | 102 +++++++++++++++++++++++++++++++++++++---\n 1 file changed, 95 insertions(+), 7 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 57e54c2..47bb7c1 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -13,6 +13,22 @@ import sys\n import os\n import json\n import shutil\n+import subprocess\n+\n+#\n+# If you want to switch to hg-git compatibility mode:\n+# git config --global remote-hg.hg-git-compat true\n+#\n+# git:\n+# Sensible defaults for git.\n+# hg bookmarks are exported as git branches, hg branches are prefixed\n+# with 'branches/'.\n+#\n+# hg:\n+# Emulate hg-git.\n+# Only hg bookmarks are exported as git branches.\n+# Commits are modified to preserve hg information and allow biridectionality.\n+#\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]+)>$')\n@@ -209,7 +225,7 @@ def mark_to_rev(mark):\n return marks.to_rev(mark)\n \n def export_ref(repo, name, kind, head):\n- global prefix, marks\n+ global prefix, marks, mode\n \n ename = '%s/%s' % (kind, name)\n tip = marks.get_tip(ename)\n@@ -244,6 +260,33 @@ def export_ref(repo, name, kind, head):\n else:\n modified, removed = get_filechanges(repo, c, parents)\n \n+ if mode == 'hg':\n+ extra_msg = ''\n+\n+ if rev_branch != 'default':\n+ extra_msg += 'branch : %s\\n' % rev_branch\n+\n+ renames = []\n+ for f in c.files():\n+ if f not in c.manifest():\n+ continue\n+ rename = c.filectx(f).renamed()\n+ if rename:\n+ renames.append((rename[0], f))\n+\n+ for e in renames:\n+ extra_msg += \"rename : %s => %s\\n\" % e\n+\n+ for key, value in extra.iteritems():\n+ if key in ('author', 'committer', 'encoding', 'message', 'branch', 'hg-git'):\n+ continue\n+ else:\n+ extra_msg += \"extra : %s : %s\\n\" % (key, urllib.quote(value))\n+\n+ desc += '\\n'\n+ if extra_msg:\n+ desc += '\\n--HG--\\n' + extra_msg\n+\n if len(parents) == 0 and rev:\n print 'reset %s/%s' % (prefix, ename)\n \n@@ -332,8 +375,18 @@ def list_branch_head(repo, cur):\n print \"@refs/heads/%s HEAD\" % head\n g_head = (head, 'branches', repo[tip])\n \n+def list_bookmark_head(repo, cur):\n+ global g_head\n+\n+ head = bookmarks.readcurrent(repo)\n+ if not head:\n+ return\n+ node = repo[head]\n+ print \"@refs/heads/%s HEAD\" % head\n+ g_head = (head, 'bookmarks', node)\n+\n def do_list(parser):\n- global branches, bmarks\n+ global branches, bmarks, mode\n \n repo = parser.repo\n for branch in repo.branchmap():\n@@ -346,9 +399,13 @@ def do_list(parser):\n \n cur = repo.dirstate.branch()\n \n- list_branch_head(repo, cur)\n- for branch in branches:\n- print \"? refs/heads/branches/%s\" % branch\n+ if mode != 'hg':\n+ list_branch_head(repo, cur)\n+ for branch in branches:\n+ print \"? refs/heads/branches/%s\" % branch\n+ else:\n+ list_bookmark_head(repo, cur)\n+\n for bmark in bmarks:\n print \"? refs/heads/%s\" % bmark\n \n@@ -414,6 +471,7 @@ def get_merge_files(repo, p1, p2, files):\n \n def parse_commit(parser):\n global marks, blob_marks, bmarks, parsed_refs\n+ global mode\n \n from_mark = merge_mark = None\n \n@@ -460,7 +518,9 @@ def parse_commit(parser):\n return of['ctx']\n is_exec = of['mode'] == 'x'\n is_link = of['mode'] == 'l'\n- return context.memfilectx(f, of['data'], is_link, is_exec, None)\n+ rename = of.get('rename', None)\n+ return context.memfilectx(f, of['data'],\n+ is_link, is_exec, rename)\n \n repo = parser.repo\n \n@@ -487,6 +547,21 @@ def parse_commit(parser):\n if merge_mark:\n get_merge_files(repo, p1, p2, files)\n \n+ if mode == 'hg':\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+ if k == 'rename':\n+ old, new = v.split(' => ', 1)\n+ files[new]['rename'] = old\n+ elif k == 'branch':\n+ extra[k] = v\n+ elif k == 'extra':\n+ ek, ev = v.split(' : ', 1)\n+ extra[ek] = urllib.unquote(ev)\n+ data = data[:i]\n+\n ctx = context.memctx(repo, (p1, p2), data,\n files.keys(), getfilectx,\n user, (date, tz), extra)\n@@ -571,12 +646,25 @@ def do_export(parser):\n def main(args):\n global prefix, dirname, branches, bmarks\n global marks, blob_marks, parsed_refs\n- global peer\n+ global peer, mode\n \n alias = args[1]\n url = args[2]\n peer = None\n \n+ cmd = ['git', 'config', '--get', 'remote-hg.hg-git-compat']\n+ hg_git_compat = False\n+ try:\n+ if subprocess.check_output(cmd) == 'true\\n':\n+ hg_git_compat = True\n+ except subprocess.CalledProcessError:\n+ pass\n+\n+ if hg_git_compat:\n+ mode = 'hg'\n+ else:\n+ mode = 'git'\n+\n if alias[4:] == url:\n is_tmp = True\n alias = util.sha1(alias).hexdigest()\n-- \n1.8.0\n"},{"id":"202025","messageId":"1351396453-29042-10-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 09/13] remote-hg: add compat for hg-git author fixes","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:09Z","receivedAt":"2012-10-28T03:54:09Z","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-hg/git-remote-hg | 59 ++++++++++++++++++++++++++++++++++++-----\n 1 file changed, 53 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 47bb7c1..3bb3192 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -14,6 +14,7 @@ import os\n import json\n import shutil\n import subprocess\n+import urllib\n \n #\n # If you want to switch to hg-git compatibility mode:\n@@ -32,6 +33,7 @@ import subprocess\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]+)>$')\n+AUTHOR_HG_RE = re.compile('^(.*?) ?<(.+?)(?:>(.+)?)?$')\n RAW_AUTHOR_RE = re.compile('^(\\w+) (?:(.+)? )?<(.+)> (\\d+) ([+-]\\d+)')\n \n def die(msg, *args):\n@@ -149,12 +151,20 @@ class Parser:\n return sys.stdin.read(size)\n \n def get_author(self):\n+ global bad_mail\n+\n+ ex = None\n m = RAW_AUTHOR_RE.match(self.line)\n if not m:\n return None\n _, name, email, date, tz = m.groups()\n+ if name and 'ext:' in name:\n+ m = re.match('^(.+?) ext:\\((.+)\\)$', name)\n+ if m:\n+ name = m.group(1)\n+ ex = urllib.unquote(m.group(2))\n \n- if email != 'unknown':\n+ if email != bad_mail:\n if name:\n user = '%s <%s>' % (name, email)\n else:\n@@ -162,6 +172,9 @@ class Parser:\n else:\n user = name\n \n+ if ex:\n+ user += ex\n+\n tz = int(tz)\n tz = ((tz / 100) * 3600) + ((tz % 100) * 60)\n return (user, int(date), -tz)\n@@ -177,9 +190,9 @@ def get_filechanges(repo, ctx, parents):\n changed, added, removed = [set(sum(e, [])) for e in zip(*l)]\n return added | changed, removed\n \n-def fixup_user(user):\n- user = user.replace('\"', '')\n+def fixup_user_git(user):\n name = mail = None\n+ user = user.replace('\"', '')\n m = AUTHOR_RE.match(user)\n if m:\n name = m.group(1)\n@@ -188,11 +201,41 @@ def fixup_user(user):\n m = NAME_RE.match(user)\n if m:\n name = m.group(1).strip()\n+ return (name, mail)\n+\n+def fixup_user_hg(user):\n+ def sanitize(name):\n+ # stole this from hg-git\n+ return re.sub('[<>\\n]', '?', name.lstrip('< ').rstrip('> '))\n+\n+ m = AUTHOR_HG_RE.match(user)\n+ if m:\n+ name = sanitize(m.group(1))\n+ mail = sanitize(m.group(2))\n+ ex = m.group(3)\n+ if ex:\n+ name += ' ext:(' + urllib.quote(ex) + ')'\n+ else:\n+ name = sanitize(user)\n+ if '@' in user:\n+ mail = name\n+ else:\n+ mail = None\n+\n+ return (name, mail)\n+\n+def fixup_user(user):\n+ global mode, bad_mail\n+\n+ if mode == 'git':\n+ name, mail = fixup_user_git(user)\n+ else:\n+ name, mail = fixup_user_hg(user)\n \n if not name:\n- name = 'Unknown'\n+ name = bad_name\n if not mail:\n- mail = 'unknown'\n+ mail = bad_mail\n \n return '%s <%s>' % (name, mail)\n \n@@ -646,7 +689,7 @@ def do_export(parser):\n def main(args):\n global prefix, dirname, branches, bmarks\n global marks, blob_marks, parsed_refs\n- global peer, mode\n+ global peer, mode, bad_mail, bad_name\n \n alias = args[1]\n url = args[2]\n@@ -662,8 +705,12 @@ def main(args):\n \n if hg_git_compat:\n mode = 'hg'\n+ bad_mail = 'none@none'\n+ bad_name = ''\n else:\n mode = 'git'\n+ bad_mail = 'unknown'\n+ bad_name = 'Unknown'\n \n if alias[4:] == url:\n is_tmp = True\n-- \n1.8.0\n"},{"id":"202027","messageId":"1351396453-29042-11-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 10/13] remote-hg: fake bookmark when there's none","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:10Z","receivedAt":"2012-10-28T03:54:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Or at least no current bookmark.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-hg/git-remote-hg | 16 ++++++++++++----\n 1 file changed, 12 insertions(+), 4 deletions(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex 3bb3192..e8e3791 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -419,12 +419,20 @@ def list_branch_head(repo, cur):\n g_head = (head, 'branches', repo[tip])\n \n def list_bookmark_head(repo, cur):\n- global g_head\n+ global g_head, bmarks\n \n head = bookmarks.readcurrent(repo)\n- if not head:\n- return\n- node = repo[head]\n+ if head:\n+ node = repo[head]\n+ else:\n+ # fake bookmark from current branch\n+ head = cur\n+ tip = get_branch_tip(repo, head)\n+ if not tip:\n+ return\n+ node = repo[tip]\n+ bmarks[head] = node\n+\n print \"@refs/heads/%s HEAD\" % head\n g_head = (head, 'bookmarks', node)\n \n-- \n1.8.0\n"},{"id":"202028","messageId":"1351396453-29042-12-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 11/13] remote-hg: add support for fake remote","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:11Z","receivedAt":"2012-10-28T03:54:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Helpful while testing.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-hg/git-remote-hg | 8 +++++++-\n 1 file changed, 7 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg\nindex e8e3791..092020f 100755\n--- a/contrib/remote-hg/git-remote-hg\n+++ b/contrib/remote-hg/git-remote-hg\n@@ -245,7 +245,13 @@ def get_repo(url, alias):\n myui = ui.ui()\n myui.setconfig('ui', 'interactive', 'off')\n \n- if hg.islocal(url):\n+ if url.startswith(\"remote://\"):\n+ remote = True\n+ url = \"file://%s\" % url[9:]\n+ else:\n+ remote = False\n+\n+ if hg.islocal(url) and not remote:\n repo = hg.repository(myui, url)\n else:\n local_path = os.path.join(dirname, 'clone')\n-- \n1.8.0\n"},{"id":"202029","messageId":"1351396453-29042-13-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 12/13] remote-hg: add tests to compare with hg-git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:12Z","receivedAt":"2012-10-28T03:54:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"The base commands come from the tests of the hg-git project.\n\nSigned-off-by: Felipe Contreras \n---\n t/t5802-remote-hg-hg-git.sh | 445 ++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 445 insertions(+)\n create mode 100755 t/t5802-remote-hg-hg-git.sh\n\ndiff --git a/t/t5802-remote-hg-hg-git.sh b/t/t5802-remote-hg-hg-git.sh\nnew file mode 100755\nindex 0000000..3cfa9e6\n--- /dev/null\n+++ b/t/t5802-remote-hg-hg-git.sh\n@@ -0,0 +1,445 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2012 Felipe Contreras\n+#\n+# Base commands from hg-git tests:\n+# https://bitbucket.org/durin42/hg-git/src\n+#\n+\n+test_description='Test remote-hg output compared to hg-git'\n+\n+. ./test-lib.sh\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+# clone to an hg repo with git\n+hg_clone_git () {\n+\t(\n+\thg init $2 &&\n+\tcd $1 &&\n+\tgit push -q \"hg::$PWD/../$2\" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'\n+\t) &&\n+\n+\t(cd $2 && hg -q update)\n+}\n+\n+# clone to a git repo with hg\n+git_clone_hg () {\n+\t(\n+\tgit init -q $2 &&\n+\tcd $1 &&\n+\thg bookmark -f -r tip master &&\n+\thg -q push -r master ../$2 || true\n+\t)\n+}\n+\n+# clone to an hg repo with hg\n+hg_clone_hg () {\n+\thg -q clone $1 $2\n+}\n+\n+# push an hg repo with git\n+hg_push_git () {\n+\t(\n+\tcd $2\n+\told=$(git symbolic-ref --short HEAD)\n+\tgit checkout -q -b tmp &&\n+\tgit fetch -q \"hg::$PWD/../$1\" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' &&\n+\tgit checkout -q $old &&\n+\tgit branch -q -D tmp 2> /dev/null || true\n+\t)\n+}\n+\n+# push an hg git repo with hg\n+hg_push_hg () {\n+\t(\n+\tcd $1 &&\n+\thg -q push ../$2 || true\n+\t)\n+}\n+\n+hg_log () {\n+\thg -R $1 log --graph --debug | grep -v 'tag: *default/'\n+}\n+\n+git_log () {\n+\tgit --git-dir=$1/.git fast-export --branches\n+}\n+\n+test_expect_success 'setup' '\n+\t(\n+\techo \"[ui]\"\n+\techo \"username = A U Thor \"\n+\techo \"[defaults]\"\n+\techo \"backout = -d \\\"0 0\\\"\"\n+\techo \"commit = -d \\\"0 0\\\"\"\n+\techo \"debugrawcommit = -d \\\"0 0\\\"\"\n+\techo \"tag = -d \\\"0 0\\\"\"\n+\techo \"[extensions]\"\n+\techo \"hgext.bookmarks =\"\n+\techo \"hggit =\"\n+\t) >> \"$HOME\"/.hgrc &&\n+\tgit config --global receive.denycurrentbranch warn\n+\tgit config --global remote-hg.hg-git-compat true\n+\n+\texport HGEDITOR=/usr/bin/true\n+\n+\texport GIT_AUTHOR_DATE=\"2007-01-01 00:00:00 +0230\"\n+\texport GIT_COMMITTER_DATE=\"$GIT_AUTHOR_DATE\"\n+'\n+\n+test_expect_success 'merge conflict 1' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\thg init hgrepo1 &&\n+\tcd hgrepo1 &&\n+\techo A > afile &&\n+\thg add afile &&\n+\thg ci -m \"origin\" &&\n+\n+\techo B > afile &&\n+\thg ci -m \"A->B\" &&\n+\n+\thg up -r0 &&\n+\techo C > afile &&\n+\thg ci -m \"A->C\" &&\n+\n+\thg merge -r1 || true &&\n+\techo C > afile &&\n+\thg resolve -m afile &&\n+\thg ci -m \"merge to C\"\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\tgit_clone_$x hgrepo1 gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\t\thg_log hgrepo2-$x > hg-log-$x &&\n+\t\tgit_log gitrepo-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'merge conflict 2' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\thg init hgrepo1 &&\n+\tcd hgrepo1 &&\n+\techo A > afile &&\n+\thg add afile &&\n+\thg ci -m \"origin\" &&\n+\n+\techo B > afile &&\n+\thg ci -m \"A->B\" &&\n+\n+\thg up -r0 &&\n+\techo C > afile &&\n+\thg ci -m \"A->C\" &&\n+\n+\thg merge -r1 || true &&\n+\techo B > afile &&\n+\thg resolve -m afile &&\n+\thg ci -m \"merge to B\"\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\tgit_clone_$x hgrepo1 gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\t\thg_log hgrepo2-$x > hg-log-$x &&\n+\t\tgit_log gitrepo-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'converged merge' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\thg init hgrepo1 &&\n+\tcd hgrepo1 &&\n+\techo A > afile &&\n+\thg add afile &&\n+\thg ci -m \"origin\" &&\n+\n+\techo B > afile &&\n+\thg ci -m \"A->B\" &&\n+\n+\techo C > afile &&\n+\thg ci -m \"B->C\" &&\n+\n+\thg up -r0 &&\n+\techo C > afile &&\n+\thg ci -m \"A->C\" &&\n+\n+\thg merge -r2 || true &&\n+\thg ci -m \"merge\"\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\tgit_clone_$x hgrepo1 gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\t\thg_log hgrepo2-$x > hg-log-$x &&\n+\t\tgit_log gitrepo-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'encoding' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\tgit init -q gitrepo &&\n+\tcd gitrepo &&\n+\n+\techo alpha > alpha &&\n+\tgit add alpha &&\n+\tgit commit -m \"add älphà\" &&\n+\n+\texport GIT_AUTHOR_NAME=\"tést èncödîng\" &&\n+\techo beta > beta &&\n+\tgit add beta &&\n+\tgit commit -m \"add beta\" &&\n+\n+\techo gamma > gamma &&\n+\tgit add gamma &&\n+\tgit commit -m \"add gämmâ\" &&\n+\n+\t: TODO git config i18n.commitencoding latin-1 &&\n+\techo delta > delta &&\n+\tgit add delta &&\n+\tgit commit -m \"add déltà\"\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\thg_clone_$x gitrepo hgrepo-$x &&\n+\t\tgit_clone_$x hgrepo-$x gitrepo2-$x &&\n+\n+\t\tHGENCODING=utf-8 hg_log hgrepo-$x > hg-log-$x &&\n+\t\tgit_log gitrepo2-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'file removal' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\tgit init -q gitrepo &&\n+\tcd gitrepo &&\n+\techo alpha > alpha &&\n+\tgit add alpha &&\n+\tgit commit -m \"add alpha\" &&\n+\techo beta > beta &&\n+\tgit add beta &&\n+\tgit commit -m \"add beta\"\n+\tmkdir foo &&\n+\techo blah > foo/bar &&\n+\tgit add foo &&\n+\tgit commit -m \"add foo\" &&\n+\tgit rm alpha &&\n+\tgit commit -m \"remove alpha\" &&\n+\tgit rm foo/bar &&\n+\tgit commit -m \"remove foo/bar\"\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\t(\n+\t\thg_clone_$x gitrepo hgrepo-$x &&\n+\t\tcd hgrepo-$x &&\n+\t\thg_log . &&\n+\t\thg manifest -r 3 &&\n+\t\thg manifest\n+\t\t) > output-$x &&\n+\n+\t\tgit_clone_$x hgrepo-$x gitrepo2-$x &&\n+\t\tgit_log gitrepo2-$x > log-$x\n+\tdone &&\n+\n+\ttest_cmp output-hg output-git &&\n+\ttest_cmp log-hg log-git\n+'\n+\n+test_expect_success 'git tags' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\t(\n+\tgit init -q gitrepo &&\n+\tcd gitrepo &&\n+\tgit config receive.denyCurrentBranch ignore &&\n+\techo alpha > alpha &&\n+\tgit add alpha &&\n+\tgit commit -m \"add alpha\" &&\n+\tgit tag alpha &&\n+\n+\techo beta > beta &&\n+\tgit add beta &&\n+\tgit commit -m \"add beta\" &&\n+\tgit tag -a -m \"added tag beta\" beta\n+\t) &&\n+\n+\tfor x in hg git; do\n+\t\thg_clone_$x gitrepo hgrepo-$x &&\n+\t\thg_log hgrepo-$x > log-$x\n+\tdone &&\n+\n+\ttest_cmp log-hg log-git\n+'\n+\n+test_expect_success 'hg author' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\tfor x in hg git; do\n+\t\t(\n+\t\tgit init -q gitrepo-$x &&\n+\t\tcd gitrepo-$x &&\n+\n+\t\techo alpha > alpha &&\n+\t\tgit add alpha &&\n+\t\tgit commit -m \"add alpha\" &&\n+\t\tgit checkout -q -b not-master\n+\t\t) &&\n+\n+\t\t(\n+\t\thg_clone_$x gitrepo-$x hgrepo-$x &&\n+\t\tcd hgrepo-$x &&\n+\n+\t\thg co master &&\n+\t\techo beta > beta &&\n+\t\thg add beta &&\n+\t\thg commit -u \"test\" -m \"add beta\" &&\n+\n+\t\techo gamma >> beta &&\n+\t\thg commit -u \"test (comment)\" -m \"modify beta\" &&\n+\n+\t\techo gamma > gamma &&\n+\t\thg add gamma &&\n+\t\thg commit -u \"\" -m \"add gamma\" &&\n+\n+\t\techo delta > delta &&\n+\t\thg add delta &&\n+\t\thg commit -u \"name\" -m \"add delta\" &&\n+\n+\t\techo epsilon > epsilon &&\n+\t\thg add epsilon &&\n+\t\thg commit -u \"name zeta &&\n+\t\thg add zeta &&\n+\t\thg commit -u \" test \" -m \"add zeta\" &&\n+\n+\t\techo eta > eta &&\n+\t\thg add eta &&\n+\t\thg commit -u \"test < test@example.com >\" -m \"add eta\" &&\n+\n+\t\techo theta > theta &&\n+\t\thg add theta &&\n+\t\thg commit -u \"test >test@example.com>\" -m \"add theta\"\n+\t\t) &&\n+\n+\t\thg_push_$x hgrepo-$x gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\n+\t\thg_log hgrepo2-$x > hg-log-$x &&\n+\t\tgit_log gitrepo-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp git-log-hg git-log-git &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'hg branch' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\tfor x in hg git; do\n+\t\t(\n+\t\tgit init -q gitrepo-$x &&\n+\t\tcd gitrepo-$x &&\n+\n+\t\techo alpha > alpha &&\n+\t\tgit add alpha &&\n+\t\tgit commit -q -m \"add alpha\" &&\n+\t\tgit checkout -q -b not-master\n+\t\t) &&\n+\n+\t\t(\n+\t\thg_clone_$x gitrepo-$x hgrepo-$x &&\n+\n+\t\tcd hgrepo-$x &&\n+\t\thg -q co master &&\n+\t\thg mv alpha beta &&\n+\t\thg -q commit -m \"rename alpha to beta\" &&\n+\t\thg branch gamma | grep -v \"permanent and global\" &&\n+\t\thg -q commit -m \"started branch gamma\"\n+\t\t) &&\n+\n+\t\thg_push_$x hgrepo-$x gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\n+\t\thg_log hgrepo2-$x > hg-log-$x &&\n+\t\tgit_log gitrepo-$x > git-log-$x\n+\tdone &&\n+\n+\ttest_cmp hg-log-hg hg-log-git &&\n+\ttest_cmp git-log-hg git-log-git\n+'\n+\n+test_expect_success 'hg tags' '\n+\tmkdir -p tmp && cd tmp &&\n+\ttest_when_finished \"cd .. && rm -rf tmp\" &&\n+\n+\tfor x in hg git; do\n+\t\t(\n+\t\tgit init -q gitrepo-$x &&\n+\t\tcd gitrepo-$x &&\n+\n+\t\techo alpha > alpha &&\n+\t\tgit add alpha &&\n+\t\tgit commit -m \"add alpha\" &&\n+\t\tgit checkout -q -b not-master\n+\t\t) &&\n+\n+\t\t(\n+\t\thg_clone_$x gitrepo-$x hgrepo-$x &&\n+\n+\t\tcd hgrepo-$x &&\n+\t\thg co master &&\n+\t\thg tag alpha\n+\t\t) &&\n+\n+\t\thg_push_$x hgrepo-$x gitrepo-$x &&\n+\t\thg_clone_$x gitrepo-$x hgrepo2-$x &&\n+\n+\t\t(\n+\t\tgit --git-dir=gitrepo-hg/.git tag -l &&\n+\t\thg_log hgrepo2-hg &&\n+\t\tcat hgrepo2-hg/.hgtags\n+\t\t) > output-$x\n+\tdone &&\n+\n+\ttest_cmp output-hg output-git\n+'\n+\n+test_done\n-- \n1.8.0\n"},{"id":"202030","messageId":"1351396453-29042-14-git-send-email-felipe.contreras@gmail.com","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH v4 13/13] remote-hg: add extra author test","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-28T03:54:13Z","receivedAt":"2012-10-28T03:54:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"For hg.hg.\n\nSigned-off-by: Felipe Contreras \n---\n t/t5802-remote-hg-hg-git.sh | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5802-remote-hg-hg-git.sh b/t/t5802-remote-hg-hg-git.sh\nindex 3cfa9e6..1f9f85c 100755\n--- a/t/t5802-remote-hg-hg-git.sh\n+++ b/t/t5802-remote-hg-hg-git.sh\n@@ -353,7 +353,11 @@ test_expect_success 'hg author' '\n \n \t\techo theta > theta &&\n \t\thg add theta &&\n-\t\thg commit -u \"test >test@example.com>\" -m \"add theta\"\n+\t\thg commit -u \"test >test@example.com>\" -m \"add theta\" &&\n+\n+\t\techo iota > iota &&\n+\t\thg add iota &&\n+\t\thg commit -u \"test example com>\" -m \"add iota\"\n \t\t) &&\n \n \t\thg_push_$x hgrepo-$x gitrepo-$x &&\n-- \n1.8.0\n"},{"id":"202103","messageId":"20121029085045.GA5023@sigill.intra.peff.net","threadId":"31960","inReplyTo":"1351396453-29042-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-29T08:50:46Z","receivedAt":"2012-10-29T08:50:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 28, 2012 at 04:54:00AM +0100, Felipe Contreras wrote:\n\n> I've ported the tests from hg-git and made sure that the output from remote-hg\n> matches the output of hg-git. With these extensive tests I would consider this\n> one ready for wide use. Not only do the tests pass, I've compared the generated\n> repos of a few projects, and the SHA-1's are exactly the same :)\n\nSounds cool. Unfortunately, the test script hangs for me, after starting\nup xxdiff (!).\n\npstree reveals that it is \"hg\" that starts it, but I didn't investigate\nbeyond that.\n\n-Peff\n"},{"id":"202124","messageId":"CAMP44s0RVe6i4DpNmaV_n7_5KO_aq2WxCPVafjsTukExRSR5Jw@mail.gmail.com","threadId":"31960","inReplyTo":"20121029085045.GA5023@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-29T14:56:39Z","receivedAt":"2012-10-29T14:56:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 29, 2012 at 9:50 AM, Jeff King wrote:\n> On Sun, Oct 28, 2012 at 04:54:00AM +0100, Felipe Contreras wrote:\n>\n>> I've ported the tests from hg-git and made sure that the output from remote-hg\n>> matches the output of hg-git. With these extensive tests I would consider this\n>> one ready for wide use. Not only do the tests pass, I've compared the generated\n>> repos of a few projects, and the SHA-1's are exactly the same :)\n>\n> Sounds cool. Unfortunately, the test script hangs for me, after starting\n> up xxdiff (!).\n>\n> pstree reveals that it is \"hg\" that starts it, but I didn't investigate\n> beyond that.\n\nYeah, the test script is not ready for merging, it needs to check for\npython, hg, and hg-git.\n\nDo you have hg-git installed?\n\nThese tests compare the output of hg-git with remote-hg. It would be\nnice to have tests that don't require hg-git, but I think what is\nthere is more than worthy of getting merged to contrib. In fact, I'm\nthinking it's ready to be out of contrib and installed by default\n(once the hg-git tests have proper checks), but I haven't heard much\nfeedback.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202137","messageId":"20121029212643.GA20513@sigill.intra.peff.net","threadId":"31960","inReplyTo":"CAMP44s0RVe6i4DpNmaV_n7_5KO_aq2WxCPVafjsTukExRSR5Jw@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-29T21:26:43Z","receivedAt":"2012-10-29T21:26:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 29, 2012 at 03:56:39PM +0100, Felipe Contreras wrote:\n\n> >> I've ported the tests from hg-git and made sure that the output from remote-hg\n> >> matches the output of hg-git. With these extensive tests I would consider this\n> >> one ready for wide use. Not only do the tests pass, I've compared the generated\n> >> repos of a few projects, and the SHA-1's are exactly the same :)\n> >\n> > Sounds cool. Unfortunately, the test script hangs for me, after starting\n> > up xxdiff (!).\n> >\n> > pstree reveals that it is \"hg\" that starts it, but I didn't investigate\n> > beyond that.\n> \n> Yeah, the test script is not ready for merging, it needs to check for\n> python, hg, and hg-git.\n> \n> Do you have hg-git installed?\n\nNo. But it's important that it fail gracefully; I can't even take it in\npu if I can't run the test suite in a sane way.\n\nI may try to figure it out later myself, but it's not a super high\npriority for me.\n\n-Peff\n"},{"id":"202140","messageId":"CAMP44s3L0ycSQFU9s157V7e-GryUdojtQ3Vk_-d2wtPf9NFtbg@mail.gmail.com","threadId":"31960","inReplyTo":"20121029212643.GA20513@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-29T21:47:04Z","receivedAt":"2012-10-29T21:47:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 29, 2012 at 10:26 PM, Jeff King wrote:\n> On Mon, Oct 29, 2012 at 03:56:39PM +0100, Felipe Contreras wrote:\n>\n>> >> I've ported the tests from hg-git and made sure that the output from remote-hg\n>> >> matches the output of hg-git. With these extensive tests I would consider this\n>> >> one ready for wide use. Not only do the tests pass, I've compared the generated\n>> >> repos of a few projects, and the SHA-1's are exactly the same :)\n>> >\n>> > Sounds cool. Unfortunately, the test script hangs for me, after starting\n>> > up xxdiff (!).\n>> >\n>> > pstree reveals that it is \"hg\" that starts it, but I didn't investigate\n>> > beyond that.\n>>\n>> Yeah, the test script is not ready for merging, it needs to check for\n>> python, hg, and hg-git.\n>>\n>> Do you have hg-git installed?\n>\n> No. But it's important that it fail gracefully; I can't even take it in\n> pu if I can't run the test suite in a sane way.\n\nThe contrib part is fine for 'pu'. The tests aren't even meant to\nexercise stuff in 'contrib', right? There might be some exceptions,\nbut either way, there's plenty of stuff in 'contrib' without any\ntests. The tests I'm providing are simply a little sugar.\n\n-- \nFelipe Contreras\n"},{"id":"202142","messageId":"20121029215631.GF20513@sigill.intra.peff.net","threadId":"31960","inReplyTo":"CAMP44s3L0ycSQFU9s157V7e-GryUdojtQ3Vk_-d2wtPf9NFtbg@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-29T21:56:32Z","receivedAt":"2012-10-29T21:56:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 29, 2012 at 10:47:04PM +0100, Felipe Contreras wrote:\n\n> >> Yeah, the test script is not ready for merging, it needs to check for\n> >> python, hg, and hg-git.\n> >>\n> >> Do you have hg-git installed?\n> >\n> > No. But it's important that it fail gracefully; I can't even take it in\n> > pu if I can't run the test suite in a sane way.\n> \n> The contrib part is fine for 'pu'. The tests aren't even meant to\n> exercise stuff in 'contrib', right? There might be some exceptions,\n> but either way, there's plenty of stuff in 'contrib' without any\n> tests. The tests I'm providing are simply a little sugar.\n\nYeah, contrib is a bit of a wildcard. Most things do not have tests.\nCompletion tests run as part of the main test suite (which to me means\nthat completion should arguably be promoted out of contrib). Subtree\ncarries its own tests that build on the test suite, but do not run all\nthe time.\n\nIf remote-hg is going to live in contrib, it probably makes sense to\nhave its tests live there, too, like subtree. It means less test\nexposure, but the robustness of the tests does not have to be as high.\nYou could also have no tests, but since you have them, it seems silly\nnot to include them. People know that items in contrib/ may not be as\nmature as the rest of git.\n\n-Peff\n"},{"id":"202146","messageId":"CAMP44s1SLpNpbjRXF6QHrOTO=_1=wjPo1_kV3jZV-HXOYXPbnQ@mail.gmail.com","threadId":"31960","inReplyTo":"20121029215631.GF20513@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-29T22:02:31Z","receivedAt":"2012-10-29T22:02:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 29, 2012 at 10:56 PM, Jeff King wrote:\n> On Mon, Oct 29, 2012 at 10:47:04PM +0100, Felipe Contreras wrote:\n>\n>> >> Yeah, the test script is not ready for merging, it needs to check for\n>> >> python, hg, and hg-git.\n>> >>\n>> >> Do you have hg-git installed?\n>> >\n>> > No. But it's important that it fail gracefully; I can't even take it in\n>> > pu if I can't run the test suite in a sane way.\n>>\n>> The contrib part is fine for 'pu'. The tests aren't even meant to\n>> exercise stuff in 'contrib', right? There might be some exceptions,\n>> but either way, there's plenty of stuff in 'contrib' without any\n>> tests. The tests I'm providing are simply a little sugar.\n>\n> Yeah, contrib is a bit of a wildcard. Most things do not have tests.\n> Completion tests run as part of the main test suite (which to me means\n> that completion should arguably be promoted out of contrib).\n\nI agree, I didn't think of that when I wrote the completion tests, but\nnow it seems appropriate, specially since there's discussion about\nmoving the prompt out of contrib.\n\n> If remote-hg is going to live in contrib, it probably makes sense to\n> have its tests live there, too, like subtree.\n\nProbably, I'll check that option.\n\nBut eventually I think it should be installed by default, unless\nsomebody can come up for a reason not to. For now contrib might be OK.\n\n> It means less test\n> exposure, but the robustness of the tests does not have to be as high.\n> You could also have no tests, but since you have them, it seems silly\n> not to include them. People know that items in contrib/ may not be as\n> mature as the rest of git.\n\nYeah, it's only a matter of figuring out how to run them.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202147","messageId":"20121029220604.GA21712@sigill.intra.peff.net","threadId":"31960","inReplyTo":"CAMP44s1SLpNpbjRXF6QHrOTO=_1=wjPo1_kV3jZV-HXOYXPbnQ@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-29T22:06:04Z","receivedAt":"2012-10-29T22:06:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 29, 2012 at 11:02:31PM +0100, Felipe Contreras wrote:\n\n> > If remote-hg is going to live in contrib, it probably makes sense to\n> > have its tests live there, too, like subtree.\n> \n> Probably, I'll check that option.\n> \n> But eventually I think it should be installed by default, unless\n> somebody can come up for a reason not to. For now contrib might be OK.\n\nI would one day like to have it as part of the main distribution, too,\nbut it would be nice to prove its worth in the field for a while first.\nI especially would like to find out how it compares in practice with the\nwork that is in msysgit.\n\n> > It means less test exposure, but the robustness of the tests does\n> > not have to be as high. You could also have no tests, but since you\n> > have them, it seems silly not to include them. People know that\n> > items in contrib/ may not be as mature as the rest of git.\n> \n> Yeah, it's only a matter of figuring out how to run them.\n\nSubtree seems to copy substantial parts of t/Makefile, but I suspect you\ncould get away with just using an \"include\". I'd also be OK with just\nincluding a test script that pulls in test-lib.sh, and letting people\nrun it manually (the Makefile infrastructure is really about running a\nlot of tests, but if there's only one script, it's not so hard).\n\n-Peff\n"},{"id":"202208","messageId":"CAMP44s2b=it8vtFDKd7F2yecm+j7C4N=YfMDt0_3LdFO3_HJNA@mail.gmail.com","threadId":"31960","inReplyTo":"20121029220604.GA21712@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-30T17:18:57Z","receivedAt":"2012-10-30T17:18:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 29, 2012 at 11:06 PM, Jeff King wrote:\n> On Mon, Oct 29, 2012 at 11:02:31PM +0100, Felipe Contreras wrote:\n>\n>> > If remote-hg is going to live in contrib, it probably makes sense to\n>> > have its tests live there, too, like subtree.\n>>\n>> Probably, I'll check that option.\n>>\n>> But eventually I think it should be installed by default, unless\n>> somebody can come up for a reason not to. For now contrib might be OK.\n>\n> I would one day like to have it as part of the main distribution, too,\n> but it would be nice to prove its worth in the field for a while first.\n> I especially would like to find out how it compares in practice with the\n> work that is in msysgit.\n\nYeah, I would like to compare it with that work, if only the patches\nwere readily available somewhere.\n\n-- \nFelipe Contreras\n"},{"id":"202209","messageId":"alpine.DEB.1.00.1210301809060.7256@s15462909.onlinehome-server.info","threadId":"31960","inReplyTo":"20121029215631.GF20513@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-10-30T17:20:48Z","receivedAt":"2012-10-30T17:20:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi all,\n\nOn Mon, 29 Oct 2012, Jeff King wrote:\n\n> On Mon, Oct 29, 2012 at 10:47:04PM +0100, Felipe Contreras wrote:\n> \n> > >> Yeah, the test script is not ready for merging, it needs to check\n> > >> for python, hg, and hg-git.\n> > >>\n> > >> Do you have hg-git installed?\n> > >\n> > > No. But it's important that it fail gracefully; I can't even take it\n> > > in pu if I can't run the test suite in a sane way.\n> > \n> > The contrib part is fine for 'pu'. The tests aren't even meant to\n> > exercise stuff in 'contrib', right? There might be some exceptions,\n> > but either way, there's plenty of stuff in 'contrib' without any\n> > tests. The tests I'm providing are simply a little sugar.\n> \n> Yeah, contrib is a bit of a wildcard. Most things do not have tests.\n\nGiven that the tests of remote-hg as in git://github.com/msysgit/git's\n'devel' branch run just fine without additional dependencies (which\nprobably triggered the not-quite-constructive and unnecessarily-flaming\n\"bloated\" comment of Felipe), and given that the code in said branch is\nwell-tested and exercised by daily use, and given the fact that my major\nconcern was not understood (and probably not addressed), and also given\nthe fact that Sverre indicated that he could finalize the work as a 20%\nproject, I decided that other projects I have to do unfortunately have a\ntoo-high priority to take care of testing and measuring the performance of\nthe patch series that is discussed in this thread.\n\nSorry,\nJohannes\n\nP.S.: I would still recommend to have a detailed look at the 'devel'\nbranch, in particular the commits starting with \"fast-export: do not refer\nto non-existing marks\" and ending with \"t5801: skip without hg\". My\nunderstanding is that it was completely ignored after a brief and maybe\ntoo-cursory look. In the least, it has a couple of lessons we learnt the\nhard way, and if git.git is dead set on duplicating the work, making these\nmistakes again could be avoided by learning from our lessons.\n"},{"id":"202214","messageId":"CAMP44s3CEGqUav-ijnzm7osD70LsjRLyOEeV3bF-LWYTCEPCSQ@mail.gmail.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210301809060.7256@s15462909.onlinehome-server.info","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-30T18:10:14Z","receivedAt":"2012-10-30T18:10:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Oct 30, 2012 at 6:20 PM, Johannes Schindelin\n wrote:\n\n> P.S.: I would still recommend to have a detailed look at the 'devel'\n> branch, in particular the commits starting with \"fast-export: do not refer\n> to non-existing marks\" and ending with \"t5801: skip without hg\". My\n> understanding is that it was completely ignored after a brief and maybe\n> too-cursory look. In the least, it has a couple of lessons we learnt the\n> hard way, and if git.git is dead set on duplicating the work, making these\n> mistakes again could be avoided by learning from our lessons.\n\n% g l --grep=\"t5801: skip without hg\" devel\n1e000d4 t5801: skip without hg\nbee410c t5801: skip without hg\n5cdc7d0 t5801: skip without hg\n05b703f t5801: skip without hg\n6bb8d90 t5801: skip without hg\nc70b4d0 t5801: skip without hg\n2f46371 t5801: skip without hg\n39bc40f t5801: skip without hg\nd0a618b t5801: skip without hg\n\n% g l --grep=\"fast-export: do not refer\" devel\nd3ac32c fast-export: do not refer to non-existing marks\nbdbb22f fast-export: do not refer to non-existing marks\n5d99930 fast-export: do not refer to non-existing marks\n381f276 fast-export: do not refer to non-existing marks\nb4686c7 fast-export: do not refer to non-existing marks\ne3dfe01 fast-export: do not refer to non-existing marks\nc00fe59 fast-export: do not refer to non-existing marks\nce357ce fast-export: do not refer to non-existing marks\n5c1c7a4 fast-export: do not refer to non-existing marks\n9c827d1 fast-export: do not refer to non-existing marks\n\nI'll assume you are referring the latest ones:\n\n% g log --oneline --reverse d3ac32c^..1e000d4\n* d3ac32c fast-export: do not refer to non-existing marks\n\nNot needed at all.\n\n* b013fe0 setup_revisions: remember whether a ref was positive or not\n* fb89a2c fast-export: do not export negative refs\n* 7655869 setup_revisions: remember whether a ref was positive or not\n\nI've fixed this problem already.\n\nThe solution proposed in these patches is to convoluted:\n1) Requires multiple unrelated changes\n2) Proposes change in committish semantics\n\nIt's hard to test, because the test to check for this is not in this\npatch series, and it's testing for something completely unrelated:\n\n---\ncat > expected << EOF\nreset refs/heads/master\nfrom $(git rev-parse master)\n\nEOF\n\ntest_expect_success 'refs are updated even if no commits need to be exported' '\n git fast-export master..master > actual &&\n test_cmp expected actual\n'\n---\n\nThis is most certainly not what we want.\n\nNotice that in my patch (a single patch) I added the tests at the same\ntime so it's clear what it's fixing, and I also added a test to the\nrelevant remote-helper behavior we want:\n\nhttps://github.com/felipec/git/commit/76e75315bd1bd8d9d8365bb09261a745a10ceae0\n\n* 512cb13 t5800: test pushing a new branch with old content\n\nIf this is what the patches above were trying to fix, then yes, my\npatch fixes that. Also, it's tainted by changes from another patch.\n\n* a85de2c t5800: point out that deleting branches does not work\n\nCorrect, but hardly _necessary_.\n\n* 2412a45 transport-helper: add trailing --\n\nNo description what's the problem, or what it's trying to fix, or\ntests, so it's not possible to know if this is _needed_ or not. But\nprobably correct.\n\n* 026d07c remote-helper: check helper status after import/export\n\nAgain, no explanation, but the issue was already addressed:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/208202\n\nThe problem is minuscule, not _needed_.\n\n* 5165e26 remote-testgit: factor out RemoteHelper class\n* 049f093 git-remote-testgit: make local a function\n* f835bb2 git_remote_helpers: add fastimport library\n* 088ad33 git-remote-hg: add hgimport, an hg-fast-import equivalent\n* 7de6ca0 git-remote-hg: add GitHg, a helper class for converting hg\ncommits to git\n* e3cc5ed git-remote-hg: add hgexport, an hg-fast-export equivalent\n* 0edc8e9 git-remote-hg: add GitExporter/GitImporter/NonLocalGit\n* 5c73277 remote-hg: adjust to hg 1.9\n* 1b47007 git-remote-hg: add the helper\n* 4dcc671 git-remote-hg: add tests\n* 48b2769 remote-hg: Postel's law dictates we should handle Author\n* 2587cc6 remote-hg: another case of Postel's law\n* 9f934c9 remote-hg: handle another funny author line from\nhttp://scelenic.com/hg\n* a799904 remote-hg: do not interfer with hg's revs() method\n\nAll these are specific to this remote-hg version.\n\n* ac77256 Always auto-gc after calling a fast-import transport\n\nThis might be a good idea, but not _needed_.\n\n* 1e000d4 t5801: skip without hg\n\nSpecific to this remote-hg.\n\n\nSo, yeah, nothing really needed there. Some patches might be nice, but\nthat's it.\n\nNow, if this is really the latest and greatest remote-hg patch series,\nI can try to port them to git's master and see how it fares.\n\nBut you mentioned something about cooperation, and I've yet to see how\nis it that you are planning to cooperate. If you say you don't have\ntime to spend on this, I don't see why I should worry about testing\nthis series of patches.\n\nAlso, you seem to be clearly against my implementation, is there any\nevidence that will convince you that my version is \"good\"? Maybe my\nversion passing more tests than msysgit's? Or is there truly nothing I\ncan do to change your perception?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202232","messageId":"alpine.DEB.1.00.1210302027410.7256@s15462909.onlinehome-server.info","threadId":"31960","inReplyTo":"CAMP44s3CEGqUav-ijnzm7osD70LsjRLyOEeV3bF-LWYTCEPCSQ@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-10-30T19:33:25Z","receivedAt":"2012-10-30T19:33:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Felipe,\n\nOn Tue, 30 Oct 2012, Felipe Contreras wrote:\n\n> But you mentioned something about cooperation, and I've yet to see how\n> is it that you are planning to cooperate. If you say you don't have time\n> to spend on this, I don't see why I should worry about testing this\n> series of patches.\n\nIt has been mentioned before that the communication style including all\nthese snarky and nasty comments is not helpful. It is hardly the first\ntime that your mails have been insulting, as can be researched easily from\nin the public mailing list archives.\n\nIn light of the indignation when advised to keep the tone down a little,\nit is probable that the mails were never put through the \"would I be\ninsulted or hurt if I was the recipient of this?\" test, as in \"do you want\nme to throw away my work?\" when you literally asked us to throw away our\nwork.\n\nSo unlike others, I do not ask you to change your tone, nor your\nwillingness to work with others. Instead, I prefer to do other things\ninstead.\n\nHth,\nJohannes\n"},{"id":"202234","messageId":"CAMP44s0akZ7_Nd1Q1AaZJuXnyTJv2MzNqDus76Y82y4LbWVO+Q@mail.gmail.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210302027410.7256@s15462909.onlinehome-server.info","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-30T20:15:39Z","receivedAt":"2012-10-30T20:15:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin\n wrote:\n> On Tue, 30 Oct 2012, Felipe Contreras wrote:\n>\n>> But you mentioned something about cooperation, and I've yet to see how\n>> is it that you are planning to cooperate. If you say you don't have time\n>> to spend on this, I don't see why I should worry about testing this\n>> series of patches.\n>\n> It has been mentioned before that the communication style including all\n> these snarky and nasty comments is not helpful.\n\nSnarky and nasty comments? How about this?\n\n---\n> As to the functionality you seek: git-remote-hg found in\n> git://github.com/msysgit/git works. It has the following advantages\n> over every other solution, including the one proposed in this thread:\n>\n> - it works\n>\n> - no really, it works\n>\n> - it supports pushes, too\n>\n> - it matured over a long time\n>\n> - there are tests\n>\n> - whenever we fixed bugs, we also added tests for the bug fixes\n>\n> - it is rock solid\n>\n> - it is in constant use\n>\n> Without push support, remote-hg is useless to me. Without regression\n> tests proving that it is rock solid, I will not use remote-hg. And I\n> will not indulge in efforts to duplicate work.\n---\n\nHow many times does somebody has to say \"it works\" before it becomes a\nsnarky comment?\n\nOr this?\n\n---\n> FTR, the reason that it's crashing is because you're lying. You're\n> saying you already have master (by means of ^master), but you don't.\n---\n\nOr this?\n\n---\n> It seems unlikely to me that this never worked, surely no reviewer\n> would accept a patch that doesn't actually implement the feature?\n> What's the history here?\n---\n\nSo what did I say?\n\n> But you mentioned something about cooperation,\n\nThat's a fact.\n\nJohannes:\n---\n> > It would be better to work together, but to me the code-styles are way\n> > too different, the difference between night and day.\n>\n> Aha. Well, okay, it was an offer to collaborate.\n---\n\n> and I've yet to see how is it that you are planning to cooperate.\n\nThis is also a fact. You haven't provided a branch, you haven't reviewed\nmy implementation, you haven't tried it. You mentioned something about\ntesting the performance, but then retracted from it.\n\nSo, if you were planning to collaborate, now it would be a good time to\nmention how.\n\n> If you say you don't have time to spend on this, I don't see why I\n> should worry about testing this series of patches.\n\nI'm just clarifying how I'm planning to spend my time, specifically if\nyou are not going to collaborate.\n\nWhat is snarky and nasty about any of these comments? I'm simply asking\nyou if you are going to collaborate and how, because I don't see it,\nand what I'm going to do.\n\nYou think that's snarkier than the comments above? Well, I disagree.\nBut I don't blame you when you are snarky, nor do I think I should.\n\n> It is hardly the first time that your mails have been insulting, as\n> can be researched easily from in the public mailing list archives.\n\nThose who want to be insulted would get insulted. I asked\na simple question \"are you going to collaborate?\", if you find that\noffensive, that's your right.\n\n> In light of the indignation when advised to keep the tone down a little,\n> it is probable that the mails were never put through the \"would I be\n> insulted or hurt if I was the recipient of this?\" test, as in \"do you want\n> me to throw away my work?\" when you literally asked us to throw away our\n> work.\n\nHow did I ask you to throw away your work? I have asked multiple times\nnow for you to provide a branch so that we can take a look and try it.\n\nI don't know of a better way to throw away code than to refuse to\nprovide it, which is what you have been doing. So, if anybody can be\nblamed of trying to throw away code, it shouldn't be me.\n\nI know you will find the previous statement offensive, but it happens to\nbe true. It is sad that you will concentrate on the statement, rather\nthan the fact, and instead of providing the branch (which will help\nto avoid throwing away the code), and thus nullify the statement, you\nchoose to be offended and complain about how offended you are.\n\nWell, I'm offended at how much you refuse to collaborate, and at how\nmuch disdain you throw at my code, but I'm not going to complain about\nme being offended; people get offended about all sorts of things. Why\nis why there's no law against offending people.\n\nInstead, I choose to do something positive about it and improve my code\nwith your criticism (e.g. lack of tests), even if that criticism is rude\nand unwarranted. But that seems to mean nothing to you.\n\n> So unlike others, I do not ask you to change your tone, nor your\n> willingness to work with others. Instead, I prefer to do other things\n> instead.\n\nI guess that answers the question; you are not going to collaborate. Got\nit.\n\nI will not ask you again for a branch with the remote-hg code.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202294","messageId":"5090EFCA.7070606@drmicha.warpmail.net","threadId":"31960","inReplyTo":"CAMP44s0akZ7_Nd1Q1AaZJuXnyTJv2MzNqDus76Y82y4LbWVO+Q@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-31T09:30:50Z","receivedAt":"2012-10-31T09:30:50Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[quotes heavily cut down by me]\nFelipe Contreras venit, vidit, dixit 30.10.2012 21:15:\n> Hi,\n> \n> On Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin\n> wrote:\n>> On Tue, 30 Oct 2012, Felipe Contreras wrote:\n>>\n>>> But you mentioned something about cooperation, and I've yet to see how\n>>> is it that you are planning to cooperate. If you say you don't have time\n>>> to spend on this, I don't see why I should worry about testing this\n>>> series of patches.\n>>\n>> It has been mentioned before that the communication style including all\n>> these snarky and nasty comments is not helpful.\n> \n\nFor the record, Johannes is not the only one being kept from looking at\nthis series (further) by the tone of this discussion. Per hominem\nattacks are neither professional nor helpful. We prefer to discuss code\nhere, just code. From my comments on an earlier version of your series\nyou can see I've tried. The way other comment threads on this series\nunfolded made me choose to be a mere by-stander again.\n\n>> and I've yet to see how is it that you are planning to cooperate.\n> \n> This is also a fact. You haven't provided a branch, you haven't reviewed\n> my implementation, you haven't tried it. You mentioned something about\n\nThis does not become true through iteration. Max' recent post 'On\ngit-remote-hg (the \"native\" one)' [1] points at the msysgit wiki on\nremote-hg [2] and his remote-hg branch [3], which is based on and points\nat Sverre's original branch [4] and mine [5] which is [4] being\nregularly rebased on origin/next. The msysgit devel branch is in heavy\nuse; I don't use mine often but run the test suite on every rebase\nbefore pushing out.\n\nIf the issues that Sverre and Dscho tried to address with their git.git\ncore (non-helper) patches turn out to be non-issues then I assume\neveryone will be happy, including them. You and they have thought a lot\nabout these things and the way hg-git sync can work. There seems to be\ndiagreement about the way fast-export/the remote helpers communicate\nwhich revs and refs that are to be synced and updated. This is not\nhg-specific, and I suggest to try and clarify that issue as thoroughly\nand calmly as possible. Everyone will benefit, and it will make clearer\nwhich tests are appropriate, and accordingly which fixes fix real problems.\n\nOrthogonal to this, it seems that all hg-git interfaces could take\nadvantage of a \"git heads\" feature if we resurrect the old ideas (can't\nfind the thread right now).\n\nHoping for the best,\nMichael\n\n[1] http://permalink.gmane.org/gmane.comp.version-control.git/201083\n[2] https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg\n[3] https://github.com/fingolfin/git/tree/remote-hg\n[4] https://github.com/SRabbelier/git/tree/remote-hg\n[5] https://github.com/mjg/git/tree/remote-hg\n"},{"id":"202296","messageId":"20121031102712.GB30879@sigill.intra.peff.net","threadId":"31960","inReplyTo":"5090EFCA.7070606@drmicha.warpmail.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-31T10:27:13Z","receivedAt":"2012-10-31T10:27:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote:\n\n> For the record, Johannes is not the only one being kept from looking at\n> this series (further) by the tone of this discussion. Per hominem\n> attacks are neither professional nor helpful. We prefer to discuss code\n> here, just code. From my comments on an earlier version of your series\n> you can see I've tried. The way other comment threads on this series\n> unfolded made me choose to be a mere by-stander again.\n\nMe too. I really like some of the directions the series is taking, and\nas the maintainer, I'd like to pick it up. But there is a big question\nmark for me still about how it relates to the work in msysgit,\nespecially:\n\n - What advantages does this implementation have over the one in\n msysgit (i.e., new features that the other one does not have)?\n\n - What disadvantages? If this implementation goes into git.git,\n the msysgit one is likely to wane in popularity. What will we be\n losing by doing so? If the answer is not \"nothing\", how hard would\n it be to port over the missing bits?\n\n - The msysgit one got held up by fixes needed for fast-export. Why\n aren't those a problem for this implementation? If we are using a\n different strategy that avoids the issue, what are the limitations\n (if any) of that strategy?\n\nI have a feeling that some of those answers are buried deep within the\ndiscussion, but I have had a hard time following all of the back and\nforth due to the volume and tone of the discussion. Are we at a point\nnow where some of the participants can try to summarize the situation?\n\nI am not saying that this implementation must be 100% better than the\nmsysgit one. I do not want perfect to to be the enemy of good and end up\nwith nothing. But at the same time, there really are two competing\nimplementations, one of which has received substantially more field use.\nEven though the msysgit one is not in git.git, it seems like the path\nfor making it happen exists (even if it has not been followed yet).\nBefore merging an alternative implementation, I would want to know what\nwe are potentially throwing away from the msysgit side, and make sure\nthat we are not following a wrong path that msysgit has already tried\nand found to be lacking.\n\n-Peff\n"},{"id":"202326","messageId":"CAMP44s2a7fmxFmdn0CAcVtX8NxVtPdBKH9RY+i_Og53jb1Ju5Q@mail.gmail.com","threadId":"31960","inReplyTo":"5090EFCA.7070606@drmicha.warpmail.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T15:39:35Z","receivedAt":"2012-10-31T15:39:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Wed, Oct 31, 2012 at 10:30 AM, Michael J Gruber\n wrote:\n> [quotes heavily cut down by me]\n> Felipe Contreras venit, vidit, dixit 30.10.2012 21:15:\n\n>> On Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin\n>> wrote:\n>>> On Tue, 30 Oct 2012, Felipe Contreras wrote:\n>>>\n>>>> But you mentioned something about cooperation, and I've yet to see how\n>>>> is it that you are planning to cooperate. If you say you don't have time\n>>>> to spend on this, I don't see why I should worry about testing this\n>>>> series of patches.\n>>>\n>>> It has been mentioned before that the communication style including all\n>>> these snarky and nasty comments is not helpful.\n>>\n>\n> For the record, Johannes is not the only one being kept from looking at\n> this series (further) by the tone of this discussion. Per hominem\n> attacks are neither professional nor helpful. We prefer to discuss code\n> here, just code.\n\nShow me a \"per hominem\" attack coming from me. I never threw any such attacks.\n\nJohannes is the one that complained about it, and that's the very\ndefinition of *not* concentrating on the code, and discussing other\ntopics.\n\n> The way other comment threads on this series\n> unfolded made me choose to be a mere by-stander again.\n\nThis is precisely ad hominem; you are ignoring the code, not because\nof the code, because of the person. This is as ad hominem as it gets.\n\nAs for how \"professional or helpful\" that is, it's debatable. The\nLinux kernel mailing list is known for being harsh, and yet, they\nmanage to get more things done than any other. They truly look at the\ncode, just the code, they don't consider criticism to the code\npersonally (nobody should), nor linger on any personal beefs that only\ndistract from the end goal.\n\n>>> and I've yet to see how is it that you are planning to cooperate.\n>>\n>> This is also a fact. You haven't provided a branch, you haven't reviewed\n>> my implementation, you haven't tried it. You mentioned something about\n>\n> This does not become true through iteration. Max' recent post\n\nThee key word is _Max's_, not Johannes'. I never said nobody did, I\nsaid Johannes didn't.\n\n> 'On\n> git-remote-hg (the \"native\" one)' [1] points at the msysgit wiki on\n> remote-hg [2] and his remote-hg branch [3], which is based on and points\n> at Sverre's original branch [4] and mine [5] which is [4] being\n> regularly rebased on origin/next. The msysgit devel branch is in heavy\n> use; I don't use mine often but run the test suite on every rebase\n> before pushing out.\n\nThis is good information, why Johannes didn't provide it? It was easy\nto copy-paste an URL. Lets suppose I did try this branch, and I come\nup with a list of problems, Johannes could easily say; \"I'm not\nresponsible for that code, I don't know what bugs could have been on\nthe rebase\". Or something along those lines, which is potentially the\nreason he didn't provide that.\n\nBut enough about Johannes, if I go on to Max's branch and give a try\nto the code, make a list of issues, run my extensive tests and so on,\nand make a report of the status, and a comparison with my code. Would\nthat make it more likely for you to stop being a by-stander?\n\nDidn't think so. The truth of the matter is that it doesn't matter\nwhat I do code-wise.\n\n> If the issues that Sverre and Dscho tried to address with their git.git\n> core (non-helper) patches turn out to be non-issues then I assume\n> everyone will be happy, including them. You and they have thought a lot\n> about these things and the way hg-git sync can work. There seems to be\n> diagreement about the way fast-export/the remote helpers communicate\n> which revs and refs that are to be synced and updated. This is not\n> hg-specific, and I suggest to try and clarify that issue as thoroughly\n> and calmly as possible. Everyone will benefit, and it will make clearer\n> which tests are appropriate, and accordingly which fixes fix real problems.\n\nI believe there is no disagreement any more, AFAICS my patches have\nbeen accepted by Sverre and Jonathan... the commit messages is another\nstory. Johannes chose not to collaborate.\n\n> Orthogonal to this, it seems that all hg-git interfaces could take\n> advantage of a \"git heads\" feature if we resurrect the old ideas (can't\n> find the thread right now).\n\nNever heard of that.\n\nYou accused me of ad hominem, now I ask you; can you ignore any\npersonal biases and look at the code, and only at the code?\n\nAnd finally, what do more do you expect me to do? About the code, and\nonly the code.\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202327","messageId":"509149D9.3070606@drmicha.warpmail.net","threadId":"31960","inReplyTo":"CAMP44s2a7fmxFmdn0CAcVtX8NxVtPdBKH9RY+i_Og53jb1Ju5Q@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-31T15:55:05Z","receivedAt":"2012-10-31T15:55:05Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:\n\n> This is precisely ad hominem; you are ignoring the code, not because\n> of the code, because of the person. This is as ad hominem as it gets.\n\nI am not rejecting your code (I reviewed an early series) but reject the\ncommunication style and manners displayed in this thread.\n\n> As for how \"professional or helpful\" that is, it's debatable. The\n> Linux kernel mailing list is known for being harsh, and yet, they\n> manage to get more things done than any other. They truly look at the\n> code, just the code, they don't consider criticism to the code\n> personally (nobody should), nor linger on any personal beefs that only\n> distract from the end goal.\n\nThere are people who choose not to be on that list because of its style.\nFor this list, I think we should follow this list's style, not that one.\n\n> But enough about Johannes, if I go on to Max's branch and give a try\n> to the code, make a list of issues, run my extensive tests and so on,\n> and make a report of the status, and a comparison with my code. Would\n> that make it more likely for you to stop being a by-stander?\n\nSure, that's what I and others have asked for.\n\n> Didn't think so. The truth of the matter is that it doesn't matter\n> what I do code-wise.\n\nJust try, seriously.\n\n>> Orthogonal to this, it seems that all hg-git interfaces could take\n>> advantage of a \"git heads\" feature if we resurrect the old ideas (can't\n>> find the thread right now).\n> \n> Never heard of that.\n> \n> You accused me of ad hominem, now I ask you; can you ignore any\n> personal biases and look at the code, and only at the code?\n\nMy efforts here prove that I either have no biases or ignore them. I'm\nnot going to ignore the style of communication, though. As a patch\nsubmitter, you (\"generic you\") want the attention of others as\nreviewers. It's in your own (again \"generic you\") interest not to put\nthem off, in the same way as it's up to the submitter to argue why a\npatch is desirable and correct.\n\nMichael\n"},{"id":"202328","messageId":"CAMP44s2u=M5RvkM0nsGuYy_BJ=0KSoFmA8Hq=CeumwvHOZYkRQ@mail.gmail.com","threadId":"31960","inReplyTo":"20121031102712.GB30879@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T15:58:59Z","receivedAt":"2012-10-31T15:58:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 11:27 AM, Jeff King wrote:\n> On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote:\n>\n>> For the record, Johannes is not the only one being kept from looking at\n>> this series (further) by the tone of this discussion. Per hominem\n>> attacks are neither professional nor helpful. We prefer to discuss code\n>> here, just code. From my comments on an earlier version of your series\n>> you can see I've tried. The way other comment threads on this series\n>> unfolded made me choose to be a mere by-stander again.\n>\n> Me too. I really like some of the directions the series is taking, and\n> as the maintainer, I'd like to pick it up. But there is a big question\n> mark for me still about how it relates to the work in msysgit,\n> especially:\n>\n> - What advantages does this implementation have over the one in\n> msysgit (i.e., new features that the other one does not have)?\n\n>From the top of my head:\n\n * Support for tags\n * Support for bookmarks\n * Support for hg-git compatibility\n * Extensive tests (truly extensive)\n * _Much_ simpler code\n * No dependencies\n\nBut let's forget about msysgit, because it's not really clear what\nseries of patches we are talking about. If we want to make a real try,\nand a real comparison, we need a clear set of patches, which seem to\nbe available only on Max Horn's repo[1].\n\n> - What disadvantages? If this implementation goes into git.git,\n> the msysgit one is likely to wane in popularity. What will we be\n> losing by doing so? If the answer is not \"nothing\", how hard would\n> it be to port over the missing bits?\n\nHonestly I am not aware of anything we would loose.\n\n> - The msysgit one got held up by fixes needed for fast-export. Why\n> aren't those a problem for this implementation? If we are using a\n> different strategy that avoids the issue, what are the limitations\n> (if any) of that strategy?\n\nI explained that already. If indeed I was looking at the right\ncommits, then I already sent patches that tackle, or otherwise deal\nwith the very same problems (albet in much simpler way). These patches\nshould have held the code, as they are not _needed_ but merely\nimproving things. The rest of the patches would barely make any\ndifference.\n\nThis is of course my guess by reading the code, I have not tried it.\n\nIn short, only this patch helps:\nhttp://article.gmane.org/gmane.comp.version-control.git/208729\n\nAnd the rest of the code should work just fine on top of latest git.git.\n\n> I have a feeling that some of those answers are buried deep within the\n> discussion, but I have had a hard time following all of the back and\n> forth due to the volume and tone of the discussion. Are we at a point\n> now where some of the participants can try to summarize the situation?\n\nLet me try to summarize the situation: Johannes is not willing to\ncollaborate, and nobody else has offered to push forward the patches\nin msysgit.\n\n> I am not saying that this implementation must be 100% better than the\n> msysgit one. I do not want perfect to to be the enemy of good and end up\n> with nothing. But at the same time, there really are two competing\n> implementations, one of which has received substantially more field use.\n> Even though the msysgit one is not in git.git, it seems like the path\n> for making it happen exists (even if it has not been followed yet).\n> Before merging an alternative implementation, I would want to know what\n> we are potentially throwing away from the msysgit side, and make sure\n> that we are not following a wrong path that msysgit has already tried\n> and found to be lacking.\n\nI also would like somebody to compare the two, so that we can have\nhealthy competition, and hopefully also cooperation. But that doesn't\nseem to be likely.\n\nSo, what to do? Should I be the one making an analysis of that code?\nSince nobody else is willing to try to compare the two, I don't see\nmany other choices, but when/if my conclusion is that my version is\nsuperior, I presume nobody would take my word for it, so what would be\nthe point?\n\nCheers.\n\n[1] http://github.com/fingolfin/git/tree/remote-hg\n\n--\nFelipe Contreras\n"},{"id":"202329","messageId":"CAMP44s2PDZwTW55NDho9DyB2XZmsG0-KH4e78grJ2OFRVZkfjg@mail.gmail.com","threadId":"31960","inReplyTo":"509149D9.3070606@drmicha.warpmail.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T16:11:39Z","receivedAt":"2012-10-31T16:11:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 4:55 PM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:\n>\n>> This is precisely ad hominem; you are ignoring the code, not because\n>> of the code, because of the person. This is as ad hominem as it gets.\n>\n> I am not rejecting your code (I reviewed an early series) but reject the\n> communication style and manners displayed in this thread.\n\nAll right, you are not rejecting it, but you are staying away from it,\nand presumably if it was coming from somebody else, you wouldn't.\n\n>> As for how \"professional or helpful\" that is, it's debatable. The\n>> Linux kernel mailing list is known for being harsh, and yet, they\n>> manage to get more things done than any other. They truly look at the\n>> code, just the code, they don't consider criticism to the code\n>> personally (nobody should), nor linger on any personal beefs that only\n>> distract from the end goal.\n>\n> There are people who choose not to be on that list because of its style.\n> For this list, I think we should follow this list's style, not that one.\n\nAnd what is this lists' style? I don't see any guidelines anywhere.\n\nBut my point wasn't that we should follow Linux's style, my point is\nthat it's debatable how one should engage in discussions.\n\nAnd yet, I haven't seen where exactly did I throw those ad hominem\nattacks. I can point you to where Johannes threw such attacks (or at\nleast snarky), to me, but I don't think that's relevant.\n\n>> But enough about Johannes, if I go on to Max's branch and give a try\n>> to the code, make a list of issues, run my extensive tests and so on,\n>> and make a report of the status, and a comparison with my code. Would\n>> that make it more likely for you to stop being a by-stander?\n>\n> Sure, that's what I and others have asked for.\n\nExcept nobody ever provided a link to the actual patches. You are the\nfirst one to do so.\n\n>> You accused me of ad hominem, now I ask you; can you ignore any\n>> personal biases and look at the code, and only at the code?\n>\n> My efforts here prove that I either have no biases or ignore them. I'm\n> not going to ignore the style of communication, though.\n\nAnd yet earlier before you said in this list \"we prefer to discuss the\ncode, just the code\", and now you are saying you are not going to\nignore the style of communication, which is not code, and yet you are\ndiscussing about it.\n\n> As a patch\n> submitter, you (\"generic you\") want the attention of others as\n> reviewers. It's in your own (again \"generic you\") interest not to put\n> them off, in the same way as it's up to the submitter to argue why a\n> patch is desirable and correct.\n\nAh, so you are making me a favor by reviewing the code?\n\nHow about we concentrate on what's good for the project? Our users\ndon't care about petty personal beefs. Support to pull and push\nmercurial repositories, _that_ they do care about.\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202337","messageId":"CAMP44s2oKMog5GygrAag8SOdwhQJr4gCZxZAwWUo-ERDzni0ag@mail.gmail.com","threadId":"31960","inReplyTo":"509149D9.3070606@drmicha.warpmail.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T18:04:31Z","receivedAt":"2012-10-31T18:04:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 4:55 PM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:\n\n>> Didn't think so. The truth of the matter is that it doesn't matter\n>> what I do code-wise.\n>\n> Just try, seriously.\n\nAll right.\n\nFirst of all, I clone the repositories pointed out:\n\ngit://github.com/fingolfin/git.git (remote-hg)\ngit://github.com/mjg/git.git (remote-hg)\ngit://github.com/msysgit/git.git (d3ac32c^..1e000d4)\n\nI rebase them on top ov v1.8.0... all 3 branches are different from\neach other. I'll pick yours.\n\n% git clone hg::~/dev/hg\nCloning into 'hg'...\nTraceback (most recent call last):\n File \"/opt/git-2/libexec/git-core/git-remote-hg\", line 101, in \n sys.exit(HgRemoteHelper().main(sys.argv))\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 196, in main\n repo = self.get_repo(alias, url)\n File \"/opt/git-2/libexec/git-core/git-remote-hg\", line 35, in get_repo\n if repo.capable('branchmap'):\nAttributeError: 'mqrepo' object has no attribute 'capable'\n\nLet's try msysgit... The same.\n\nMax's? The same.\n\nMaybe it's just the setup and the tests actually pass?\n\n# failed 11 among 14 test(s)\n\nNope.\n\nAll right, it probably doesn't work with recent versions of mercurial.\nLet's try with hg v2.2:\n\n# failed 4 among 14 test(s)\n\nAll right, that's progress.\n\nCan I clone now?\n\n% git clone hg::~/dev/hg\nCloning into 'hg'...\nprogress Exported revision 0.\nprogress Exported revision 1000.\nfatal: Missing space before < in ident string: Anupam\nKapoor 1127407335 -0700\nfast-import: dumping crash report to /tmp/hg/.git/fast_import_crash_18197\nfatal: Error while running fast-import\nTraceback (most recent call last):\n File \"/opt/git-2/libexec/git-core/git-remote-hg\", line 101, in \n sys.exit(HgRemoteHelper().main(sys.argv))\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 204, in main\n more = self.read_one_line(repo)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 169, in read_one_line\n func(repo, cmdline)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 108, in do_import\n repo.exporter.export_repo(repo.gitdir, refs)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/exporter.py\",\nline 27, in export_repo\n exporter.export_repo(refs)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 246, in export_repo\n exported = self.export_revision(ctx) or exported\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 215, in export_revision\n self.export_files(ctx)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 190, in export_files\n self.write_file(ctx, name, idnum)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 105, in write_file\n self.write_blob(data, idnum)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 99, in write_blob\n self.write_data(data)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 91, in write_data\n self.write(data, LF)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 52, in write\n sys.stdout.write(msg)\nIOError: [Errno 32] Broken pipe\n\nNope.\n\nAll right, let's go back to hg v1.9 (Jun 2011).\n\n# passed all 14 test(s)\n\nYay!\n\n% git clone hg::~/dev/hg\nCloning into 'hg'...\nprogress Exported revision 0.\nprogress Exported revision 1000.\nfatal: Missing space before < in ident string: Anupam\nKapoor 1127407335 -0700\nfast-import: dumping crash report to /tmp/hg/.git/fast_import_crash_18646\nfatal: Error while running fast-import\nTraceback (most recent call last):\n File \"/opt/git-2/libexec/git-core/git-remote-hg\", line 101, in\n\n sys.exit(HgRemoteHelper().main(sys.argv))\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 204, in main\n more = self.read_one_line(repo)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 169, in read_one_line\n func(repo, cmdline)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py\",\nline 108, in do_import\n repo.exporter.export_repo(repo.gitdir, refs)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/exporter.py\",\nline 27, in export_repo\n exporter.export_repo(refs)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 246, in export_repo\n exported = self.export_revision(ctx) or exported\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 215, in export_revision\n self.export_files(ctx)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 190, in export_files\n self.write_file(ctx, name, idnum)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 105, in write_file\n self.write_blob(data, idnum)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 99, in write_blob\n self.write_data(data)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 91, in write_data\n self.write(data, LF)\n File \"/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py\",\nline 52, in write\n sys.stdout.write(msg)\nIOError: [Errno 32] Broken pipe\n\nStill doesn't work.\n\nLet's try msysgit.\n\n% git clone hg::~/dev/hg\nCloning into 'hg'...\nprogress Exported revision 0.\nprogress Exported revision 1000.\nprogress Exported revision 2000.\nprogress Exported revision 3000.\nprogress Exported revision 4000.\nprogress Exported revision 5000.\nprogress Exported revision 6000.\nprogress Exported revision 7000.\nprogress Exported revision 8000.\nprogress Exported revision 9000.\nprogress Exported revision 10000.\nprogress Exported revision 11000.\nprogress Exported revision 12000.\nprogress Exported revision 13000.\nprogress Exported revision 14000.\nprogress Exported revision 15000.\nprogress Exported revision 16000.\nprogress Exported revision 17000.\n\nFinally!\n\nLet's run my tests:\n\ntest.sh:\n# failed 1 among 1 test(s)\n\ntest-bidi.sh:\n# failed 5 among 6 test(s)\n\ntest-hg-git.sh\n# failed 9 among 10 test(s)\n\nOther than the setup tests which really don't exercise any code, all\nthe tests fail.\n\nAnd it's not only a silly error like couldn't find remote-hg; the\ntests do really fail:\n\nTraceback (most recent call last):\n File \"/home/felipec/dev/git-other-remote-hg/git-remote-hg\", line\n101, in \n sys.exit(HgRemoteHelper().main(sys.argv))\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py\",\nline 204, in main\n more = self.read_one_line(repo)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py\",\nline 169, in read_one_line\n func(repo, cmdline)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py\",\nline 122, in do_export\n localrepo.importer.do_import(localrepo.gitdir)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/importer.py\",\nline 27, in do_import\n processor.parseMany(sources, parser.ImportParser, procc)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/fastimport/processor.py\",\nline 219, in parseMany\n processor.process(parser.parse())\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/fastimport/processor.py\",\nline 76, in process\n handler(self, cmd)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/hgimport.py\",\nline 262, in commit_handler\n self.idmap[cmd.id] = self.putcommit(modified, modes, copies, cmt)\n File \"/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/hgimport.py\",\nline 294, in putcommit\n self.repo.commitctx(ctx)\n File \"/home/felipec/dev/hg/mercurial/localrepo.py\", line 1112, in commitctx\n user, ctx.date(), ctx.extra().copy())\n File \"/home/felipec/dev/hg/mercurial/changelog.py\", line 213, in add\n user, desc = encoding.fromlocal(user), encoding.fromlocal(desc)\n File \"/home/felipec/dev/hg/mercurial/encoding.py\", line 133, in fromlocal\n raise error.Abort(\"decoding near '%s': %s!\" % (sub, inst))\nmercurial.error.Abort: decoding near 'add älphà\n': 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in\nrange(128)!\n\nLet's gather what we have:\n\n* msysgit: works in hg v2.2, but not hg v2.3\n* yours: kind of works on hg v1.9, but not really\n* Max's: works on hg v2.2, but not hg v2.3\n\nNone of them pass even one of my tests.\n\nNow lets remove all the supposed required patches to git core:\n\n# passed all 14 test(s)\n\nBut that doesn't really say much, these tests are _really_ simple.\n\nHow about performance?\n\n Performance counter stats for 'git clone hg::~/dev/hg':\n\n 241391.332748 task-clock # 1.387 CPUs utilized\n 53,357 context-switches # 0.221 K/sec\n 3,797 CPU-migrations # 0.016 K/sec\n 1,258,346 page-faults # 0.005 M/sec\n 433,914,358,895 cycles # 1.798 GHz\n 185,410,787,111 stalled-cycles-frontend # 42.73% frontend cycles idle\n stalled-cycles-backend\n 581,663,561,600 instructions # 1.34 insns per cycle\n # 0.32 stalled cycles per insn\n 101,993,199,721 branches # 422.522 M/sec\n 5,208,212,657 branch-misses # 5.11% of all branches\n\n 174.038642915 seconds time elapsed\n\nCompared to;\n\n Performance counter stats for 'git clone hg::~/dev/hg':\n\n 412892.981091 task-clock # 1.211 CPUs utilized\n 200,029 context-switches # 0.484 K/sec\n 9,288 CPU-migrations # 0.022 K/sec\n 632,783 page-faults # 0.002 M/sec\n 741,785,312,967 cycles # 1.797 GHz\n 306,533,270,745 stalled-cycles-frontend # 41.32% frontend cycles idle\n stalled-cycles-backend\n 1,012,488,224,809 instructions # 1.36 insns per cycle\n # 0.30 stalled cycles per insn\n 168,056,255,731 branches # 407.021 M/sec\n 9,528,432,325 branch-misses # 5.67% of all branches\n\n 340.976843750 seconds time elapsed\n\nLooks like there's something to improve in this area, but I wouldn't\nbe surprised if the reason for the better performance is that\nsomething is not being done. I'll investigate.\n\nAnd all this for the low price of:\n\n .gitignore | 1 +\n Makefile | 1 +\n git-remote-hg.py | 101 +++++++++++\n git-remote-testgit.py | 295\n++++++------------------------\n git_remote_helpers/fastimport/commands.py | 469\n+++++++++++++++++++++++++++++++++++++++++++++++\n git_remote_helpers/fastimport/dates.py | 79 ++++++++\n git_remote_helpers/fastimport/errors.py | 182 +++++++++++++++++++\n git_remote_helpers/fastimport/head_tracker.py | 47 +++++\n git_remote_helpers/fastimport/helpers.py | 88 +++++++++\n git_remote_helpers/fastimport/idmapfile.py | 65 +++++++\n git_remote_helpers/fastimport/parser.py | 621\n+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n git_remote_helpers/fastimport/processor.py | 222 +++++++++++++++++++++++\n git_remote_helpers/git/importer.py | 30 +--\n git_remote_helpers/git/repo.py | 8 +-\n git_remote_helpers/helper.py | 207 +++++++++++++++++++++\n git_remote_helpers/hg/exporter.py | 29 +++\n git_remote_helpers/hg/hg.py | 126 +++++++++++++\n git_remote_helpers/hg/hgexport.py | 280\n++++++++++++++++++++++++++++\n git_remote_helpers/hg/hgimport.py | 401\n+++++++++++++++++++++++++++++++++++++++++\n git_remote_helpers/hg/importer.py | 29 +++\n git_remote_helpers/hg/non_local.py | 51 ++++++\n git_remote_helpers/hg/util.py | 14 ++\n git_remote_helpers/setup.py | 3 +-\n t/t5800-remote-helpers.sh | 19 ++\n t/t5801-remote-hg.sh | 143 +++++++++++++++\n 25 files changed, 3242 insertions(+), 269 deletions(-)\n\nCompared to:\n\n contrib/remote-hg/Makefile | 13 ++\n contrib/remote-hg/git-remote-hg | 780\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n contrib/remote-hg/test-bidi.sh | 241 ++++++++++++++++++++++++\n contrib/remote-hg/test-hg-git.sh | 464\n+++++++++++++++++++++++++++++++++++++++++++++\n contrib/remote-hg/test.sh | 45 +++++\n 5 files changed, 1543 insertions(+)\n\nNow, sure, I am biased, but the truth is I don't know of a single\nfeature that this remote-hg supports that my version doesn't. If\nthere's any, I'm all ears; I'll implement it right away.\n\nAt no point in time did I ever suggested this code to be thrown away,\nbut if there's any possibility salvaging some of this code, they only\nway I see it is if I myself do it, because nobody has stepped up to\nwork on this. And quite frankly, I think I've already done more than\nenough, so...\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202338","messageId":"alpine.DEB.1.00.1210311900450.7256@s15462909.onlinehome-server.info","threadId":"31960","inReplyTo":"20121031102712.GB30879@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-10-31T18:20:51Z","receivedAt":"2012-10-31T18:20:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Wed, 31 Oct 2012, Jeff King wrote:\n\n> I really like some of the directions the series is taking, and as the\n> maintainer, I'd like to pick it up.\n\nCode-wise, I agree.\n\n> But there is a big question mark for me still about how it relates to\n> the work in msysgit, especially:\n> \n> - What advantages does this implementation have over the one in\n> msysgit (i.e., new features that the other one does not have)?\n\nDisclaimer: I do not know the details (as I said, I have higher priorities\nelsewhere since the remote-hg I need for everyday work continues to do its\njob, and the patch series bringing Python to msysGit is more pressing,\nand I will enjoy its review much more, too).\n\nThe biggest advantage seems to me that it was started later than msysGit's\nremote-hg and as such could potentially exploit recent improvements in\ngit.git.\n\n> - What disadvantages? If this implementation goes into git.git,\n> the msysgit one is likely to wane in popularity. What will we be\n> losing by doing so? If the answer is not \"nothing\", how hard would\n> it be to port over the missing bits?\n\nThe biggest advantage msysGit's series has is that it had a fix for a\nfundamental flaw in fast-export. Fast-export was intended to work\nincrementally, so the incantation \"git branch blub master && git\nfast-export ^master blub\" is expected to update the ref \"blub\" properly.\n\nI just tested this with junio/next and it seems this issue is still\nunfixed: instead of\n\n\treset refs/heads/blub\n\tfrom e7510461b7db54b181d07acced0ed3b1ada072c8\n\nI get\n\n\treset refs/heads/blub\n\tfrom :0\n\nwhen running \"git fast-export ^master blub\".\n\nHaving said that, we have no problem to throw away the fix that was\nrejected by Junio (who wanted something much more general which I refused\nto implement both due to lack of time and lack of need -- think YAGNI) and\nrebase our stuff on top of whatever goes into git.git's next (or master,\nwe are still deciding in the msysGit project whether we should stop\ntracking next).\n\nAnother thing that I really like about remote-hg as it is in msysGit is\nthat it was designed with extensibility in mind. It should not be too hard\nto support other fast-import/export based backends using that\ninfrastructure. I am particularly interested in bzr myself, but there is\nno day-job related project I could use as an excuse to give that project\na higher priority that the other things I am doing at the moment.\n\n> - The msysgit one got held up by fixes needed for fast-export. Why\n> aren't those a problem for this implementation? If we are using a\n> different strategy that avoids the issue, what are the limitations (if\n> any) of that strategy?\n\nJunio wanted a more general solution, adding infrastructure to the\nrev-list engine that I did not need -- and did not see the need for,\neither -- and given the amount of time I had invested in a working\nremote-hg and given that I needed it desperately for my day-job project, I\ndecided to just put it into msysGit and give up my hopes for it to become\nofficial.\n\nIt has worked well in the meantime and met my needs. The only thing\nmissing is the support for octopus merges. But I would need that only to\nsatisfy my geek self: I would set up an automatic Hg mirror of git.git\nitself on bitbucket.\n\n> I have a feeling that some of those answers are buried deep within the\n> discussion, but I have had a hard time following all of the back and\n> forth due to the volume and tone of the discussion. Are we at a point\n> now where some of the participants can try to summarize the situation?\n\nHopefully my attempt met your expectations.\n\nThank you,\nDscho\n"},{"id":"202340","messageId":"CAMP44s2y-co4TELg28==axRmbF7xq3Qp7U8wjg6XtGAUMgf40w@mail.gmail.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210311900450.7256@s15462909.onlinehome-server.info","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T18:41:28Z","receivedAt":"2012-10-31T18:41:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin\n wrote:\n\n>> - What disadvantages? If this implementation goes into git.git,\n>> the msysgit one is likely to wane in popularity. What will we be\n>> losing by doing so? If the answer is not \"nothing\", how hard would\n>> it be to port over the missing bits?\n>\n> The biggest advantage msysGit's series has is that it had a fix for a\n> fundamental flaw in fast-export. Fast-export was intended to work\n> incrementally, so the incantation \"git branch blub master && git\n> fast-export ^master blub\" is expected to update the ref \"blub\" properly.\n>\n> I just tested this with junio/next and it seems this issue is still\n> unfixed: instead of\n>\n> reset refs/heads/blub\n> from e7510461b7db54b181d07acced0ed3b1ada072c8\n>\n> I get\n>\n> reset refs/heads/blub\n> from :0\n>\n> when running \"git fast-export ^master blub\".\n\nThat is not a problem. It has been discussed extensively, and the\nconsensus seems to be that such command should throw nothing:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/208729\n\nBut that doesn't affect remote helpers, what we _really_ want is for\nthis to work:\n\ngit fast-export --import-marks=tmp-marks \\\n --export-marks=tmp-marks master > /dev/null &&\ngit fast-export --import-marks=tmp-marks \\\n --export-marks=tmp-marks blub > actual &&\n\nAnd that's fixed in this patch: (for which the consensus seems to be\nthat it's also OK)\n\nhttp://article.gmane.org/gmane.comp.version-control.git/208730\n\nBut none of these patches are *required* for remote-hg (any of them) to work.\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202341","messageId":"20121031185903.GA1480@elie.Belkin","threadId":"31960","inReplyTo":"CAMP44s2y-co4TELg28==axRmbF7xq3Qp7U8wjg6XtGAUMgf40w@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-10-31T18:59:03Z","receivedAt":"2012-10-31T18:59:03Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin\n> wrote:\n\n>> I just tested this with junio/next and it seems this issue is still\n>> unfixed: instead of\n>>\n>> reset refs/heads/blub\n>> from e7510461b7db54b181d07acced0ed3b1ada072c8\n>>\n>> I get\n>>\n>> reset refs/heads/blub\n>> from :0\n>>\n>> when running \"git fast-export ^master blub\".\n>\n> That is not a problem. It has been discussed extensively, and the\n> consensus seems to be that such command should throw nothing:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/208729\n\nUm. Are you claiming I have said that \"git fast-export ^master blub\"\nshould silently emit nothing? Or has this been discussed extensively\nwith someone else?\n\nJonathan\n"},{"id":"202342","messageId":"CAMP44s2-UoT03OeTmM9=nh9wCUt84exPNuHyuThp=WQkxvCNLQ@mail.gmail.com","threadId":"31960","inReplyTo":"20121031185903.GA1480@elie.Belkin","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T19:24:53Z","receivedAt":"2012-10-31T19:24:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Wed, Oct 31, 2012 at 7:59 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin\n>> wrote:\n>\n>>> I just tested this with junio/next and it seems this issue is still\n>>> unfixed: instead of\n>>>\n>>> reset refs/heads/blub\n>>> from e7510461b7db54b181d07acced0ed3b1ada072c8\n>>>\n>>> I get\n>>>\n>>> reset refs/heads/blub\n>>> from :0\n>>>\n>>> when running \"git fast-export ^master blub\".\n>>\n>> That is not a problem. It has been discussed extensively, and the\n>> consensus seems to be that such command should throw nothing:\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/208729\n>\n> Um. Are you claiming I have said that \"git fast-export ^master blub\"\n> should silently emit nothing? Or has this been discussed extensively\n> with someone else?\n\nMaybe I misunderstood when you said:\n> A patch meeting the above description would make perfect sense to me.\n\nAnyway, when you have:\n\n% git fast-export ^next next^{commit}\n# nothing\n% git fast-export ^next next~0\n# nothing\n% git fast-export ^next next~1\n# nothing\n% git fast-export ^next next~2\n# nothing\n\nIt only makes sense that:\n\n% git fast-export ^next next\n# nothing\n\nIt doesn't get any more obvious than that. But to each his own.\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202343","messageId":"CAMP44s0KFJW2F3gbO_Xd9QKrZ1OoxvUCvecU084-zH2UDqXKag@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s2oKMog5GygrAag8SOdwhQJr4gCZxZAwWUo-ERDzni0ag@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T19:47:43Z","receivedAt":"2012-10-31T19:47:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 7:04 PM, Felipe Contreras\n wrote:\n\n> How about performance?\n\n> 174.038642915 seconds time elapsed\n>\n> Compared to;\n\n> 340.976843750 seconds time elapsed\n>\n> Looks like there's something to improve in this area, but I wouldn't\n> be surprised if the reason for the better performance is that\n> something is not being done. I'll investigate.\n\nTurns out msysgit's remote-hg is not exporting the whole repository,\nthat's why it's faster =/\n\nLet's try with a smaller repo:\n\n Performance counter stats for 'git clone hg::~/dev/love love-2':\n\n 16130.554299 task-clock # 1.311 CPUs utilized\n 5,625 context-switches # 0.349 K/sec\n 241 CPU-migrations # 0.015 K/sec\n 84,042 page-faults # 0.005 M/sec\n 28,985,094,782 cycles # 1.797 GHz\n 12,235,424,421 stalled-cycles-frontend # 42.21% frontend cycles idle\n stalled-cycles-backend\n 38,762,850,763 instructions # 1.34 insns per cycle\n # 0.32 stalled cycles per insn\n 6,727,815,043 branches # 417.085 M/sec\n 354,887,290 branch-misses # 5.27% of all branches\n\n 12.300536156 seconds time elapsed\n\nAnd mine:\n\n Performance counter stats for 'git clone hg::~/dev/love love-1':\n\n 16116.643370 task-clock # 1.295 CPUs utilized\n 6,270 context-switches # 0.389 K/sec\n 183 CPU-migrations # 0.011 K/sec\n 57,767 page-faults # 0.004 M/sec\n 28,962,073,772 cycles # 1.797 GHz\n 11,844,122,698 stalled-cycles-frontend # 40.90% frontend cycles idle\n stalled-cycles-backend\n 39,679,556,857 instructions # 1.37 insns per cycle\n # 0.30 stalled cycles per insn\n 6,609,397,307 branches # 410.098 M/sec\n 371,092,848 branch-misses # 5.61% of all branches\n\n 12.446643210 seconds time elapsed\n\nThat's more like it. msysgit's is still missing a few commits, but\nnothing mayor.\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"202344","messageId":"alpine.DEB.1.00.1210312126080.7256@s15462909.onlinehome-server.info","threadId":"31960","inReplyTo":"CAMP44s2-UoT03OeTmM9=nh9wCUt84exPNuHyuThp=WQkxvCNLQ@mail.gmail.com","subject":"Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-10-31T20:28:22Z","receivedAt":"2012-10-31T20:28:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2012, Felipe Contreras wrote:\n\n> It doesn't get any more obvious than that. But to each his own.\n\nIn my opinion, Jonathan does not deserve any of such condescending words.\nBut maybe the Git maintainers are okay with such a tone on this list?\n\nHth,\nJohannes\n"},{"id":"202345","messageId":"CAMP44s3WJWRCMfoztrATmUbJ7KZOw46Q2tk2Dse8a=No27nmhA@mail.gmail.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210312126080.7256@s15462909.onlinehome-server.info","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-10-31T20:37:30Z","receivedAt":"2012-10-31T20:37:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 9:28 PM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Wed, 31 Oct 2012, Felipe Contreras wrote:\n>\n>> It doesn't get any more obvious than that. But to each his own.\n>\n> In my opinion, Jonathan does not deserve any of such condescending words.\n> But maybe the Git maintainers are okay with such a tone on this list?\n\nJonathan and I already agreed to disagree, there's nothing wrong with\nthat. To me the above behavior is obviously correct, to him it's not.\nEverybody is entitled to their own opinion, are we not?\n\n-- \nFelipe Contreras\n"},{"id":"202347","messageId":"alpine.LNX.2.00.1210311613550.3197@iabervon.org","threadId":"31960","inReplyTo":"CAMP44s2-UoT03OeTmM9=nh9wCUt84exPNuHyuThp=WQkxvCNLQ@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2012-10-31T23:14:02Z","receivedAt":"2012-10-31T23:14:02Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Oct 2012, Felipe Contreras wrote:\n\n> Hi,\n> \n> On Wed, Oct 31, 2012 at 7:59 PM, Jonathan Nieder wrote:\n> > Felipe Contreras wrote:\n> >> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin\n> >> wrote:\n> >\n> >>> I just tested this with junio/next and it seems this issue is still\n> >>> unfixed: instead of\n> >>>\n> >>> reset refs/heads/blub\n> >>> from e7510461b7db54b181d07acced0ed3b1ada072c8\n> >>>\n> >>> I get\n> >>>\n> >>> reset refs/heads/blub\n> >>> from :0\n> >>>\n> >>> when running \"git fast-export ^master blub\".\n> >>\n> >> That is not a problem. It has been discussed extensively, and the\n> >> consensus seems to be that such command should throw nothing:\n> >>\n> >> http://article.gmane.org/gmane.comp.version-control.git/208729\n> >\n> > Um. Are you claiming I have said that \"git fast-export ^master blub\"\n> > should silently emit nothing? Or has this been discussed extensively\n> > with someone else?\n> \n> Maybe I misunderstood when you said:\n> > A patch meeting the above description would make perfect sense to me.\n> \n> Anyway, when you have:\n> \n> % git fast-export ^next next^{commit}\n> # nothing\n> % git fast-export ^next next~0\n> # nothing\n> % git fast-export ^next next~1\n> # nothing\n> % git fast-export ^next next~2\n> # nothing\n> \n> It only makes sense that:\n> \n> % git fast-export ^next next\n> # nothing\n> \n> It doesn't get any more obvious than that. But to each his own.\n\nI think that may be true where you have \"next\" in both places, but I \nthink:\n\n$ git checkout -b new-branch master\n$ git fast-export ^master new-branch\n\nought to emit no \"commit\" lines, but needs to emit a \"reset\" line. After \nall, you haven't told fast-export that the ref \"new-branch\" is up to date, \nand you have told it that you want it to be exported. If you create a new \nbranch off of an existing commit, don't change it, and push it to hg, it \nshouldn't be up to remote-hg to figure out what should happen with no \ninput; it should get a:\n\nreset refs/heads/new-branch\nfrom [something]\n\nI don't know why Johannes seems to want [something] not to be a mark \nreference (unless he's complaining about getting an invalid mark \nreference when there aren't any marks defined), but surely something of \nthe above form is necessary to tell remote-hg to create the new branch.\n\nI think it would be worth testing that:\n\n$ git checkout -b new-branch master\n$ git push hg new-branch\n\ncreates the new branch successfully (which I think it does, but wouldn't \nif \"git fast-export ^master new-branch\" actually returned nothing; \nparsed_refs gets it from the reset line).\n\nAFAICT, your code relies on getting the behavior that fast-export actually \ngives, not the behavior you seem to want or the behavior Johannes seems to \nwant. And the reason that you don't need any changes to fast-export is \nthat your process maps marks instead of sha1s.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"202348","messageId":"16b87432-2862-4be9-afea-5b672101af62@email.android.com","threadId":"31960","inReplyTo":"CAMP44s2a7fmxFmdn0CAcVtX8NxVtPdBKH9RY+i_Og53jb1Ju5Q@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-01T01:22:49Z","receivedAt":"2012-11-01T01:22:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\nFelipe Contreras wrote:\n\n>And finally, what do more do you expect me to do? About the code, and\n>only the code.\n\nThe analysis that does in the log messages is an important part of \"code\" in this project, so that may be a good place to start. Both Jonathan and J6t asked specific updates to your log message, no?\n"},{"id":"202349","messageId":"bec4d263-b458-4636-9fa6-1c1202416810@email.android.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210312126080.7256@s15462909.onlinehome-server.info","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-01T01:32:17Z","receivedAt":"2012-11-01T01:32:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\nJohannes Schindelin wrote:\n\n>On Wed, 31 Oct 2012, Felipe Contreras wrote:\n>\n>> It doesn't get any more obvious than that. But to each his own.\n>\n>In my opinion, Jonathan does not deserve any of such condescending\n>words.\n>But maybe the Git maintainers are okay with such a tone on this list?\n\nAgreed, and no.\n\nWe've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one.\n"},{"id":"202350","messageId":"c0f8d214-4d61-4b02-8bda-4f26c33ae30f@email.android.com","threadId":"31960","inReplyTo":"alpine.DEB.1.00.1210311900450.7256@s15462909.onlinehome-server.info","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-01T01:41:11Z","receivedAt":"2012-11-01T01:41:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\nJohannes Schindelin wrote:\n\n>Junio wanted a more general solution, adding infrastructure to the\n>rev-list engine that I did not need -- and did not see the need for,\n>either -- and given the amount of time I had invested in a working\n>remote-hg and given that I needed it desperately for my day-job\n>project, ...\n\nThis is relatively long ago (and I am away from my machine, so I cannot check) so I may misremembering things, but my impression is that since that discussion, we added a minimal \"infrastructure\" to the rev-list (I think we caled it rev-list-cmdline or something like that) and Sverre used it to update fast-export.\n\nIt may well be that what we have is still not sufficient to do everything you need, but it may be close enough to get extended for your original use case.\n"},{"id":"202352","messageId":"CAMP44s1v5Au7=Pt-_9MV54VGC-SiTte=aL0S9ekZB9yxiU+wKw@mail.gmail.com","threadId":"31960","inReplyTo":"alpine.LNX.2.00.1210311613550.3197@iabervon.org","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T02:46:55Z","receivedAt":"2012-11-01T02:46:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 12:14 AM, Daniel Barkalow wrote:\n\n> I think that may be true where you have \"next\" in both places, but I\n> think:\n>\n> $ git checkout -b new-branch master\n> $ git fast-export ^master new-branch\n>\n> ought to emit no \"commit\" lines, but needs to emit a \"reset\" line. After\n> all, you haven't told fast-export that the ref \"new-branch\" is up to date,\n> and you have told it that you want it to be exported. If you create a new\n> branch off of an existing commit, don't change it, and push it to hg, it\n> shouldn't be up to remote-hg to figure out what should happen with no\n> input; it should get a:\n>\n> reset refs/heads/new-branch\n> from [something]\n>\n> I don't know why Johannes seems to want [something] not to be a mark\n> reference (unless he's complaining about getting an invalid mark\n> reference when there aren't any marks defined), but surely something of\n> the above form is necessary to tell remote-hg to create the new branch.\n\nI don't know what Johannes wants, but it has been discussed that not\neverybody is using marks.\n\nWhen you use marks, the following patch fixes the issue:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/208730\n\n> I think it would be worth testing that:\n>\n> $ git checkout -b new-branch master\n> $ git push hg new-branch\n>\n> creates the new branch successfully (which I think it does, but wouldn't\n> if \"git fast-export ^master new-branch\" actually returned nothing;\n> parsed_refs gets it from the reset line).\n\nAnd it does, with the above patch, a similar command is even in the tests.\n\nThe reason why 'git fast-export ^master new-branch' returning nothing\ndoesn't affect, is that transport helpers wouldn't use negative refs\n(e.g. ^master). Transport helper passes whatever the uses specifies. I\nyou say 'new-branch', that's exactly what the transport helper will\nreceive. It works because transport helpers use marks.\n\nNobody expects '^master new-branch' to do something useful, everybody\nuses marks.\n\n> AFAICT, your code relies on getting the behavior that fast-export actually\n> gives, not the behavior you seem to want or the behavior Johannes seems to\n> want. And the reason that you don't need any changes to fast-export is\n> that your process maps marks instead of sha1s.\n\nNo. In order to make use of this bug, the user would have to do:\n\n% git push hg ^master new-branch\n\nOtherwise nothing would get pushed, with or without my first patch[1].\nTo make 'git push hg new-branch' work, you need my second patch[2].\n\nCheers.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/208729\n[2] http://article.gmane.org/gmane.comp.version-control.git/208730\n\n-- \nFelipe Contreras\n"},{"id":"202353","messageId":"CAMP44s3AOT4+Zz+CgZD7VXTGhKVQac+w0XQ8_VKzsi-ZGmo+fg@mail.gmail.com","threadId":"31960","inReplyTo":"16b87432-2862-4be9-afea-5b672101af62@email.android.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T02:50:19Z","receivedAt":"2012-11-01T02:50:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 2:22 AM, Junio C Hamano wrote:\n>\n>\n> Felipe Contreras wrote:\n>\n>>And finally, what do more do you expect me to do? About the code, and\n>>only the code.\n>\n> The analysis that does in the log messages is an important part of \"code\" in this project, so that may be a good place to start. Both Jonathan and J6t asked specific updates to your log message, no?\n\nRegarding git-remote-hg? No. They haven't said anything about any of\nthose patches.\n\n-- \nFelipe Contreras\n"},{"id":"202354","messageId":"CAMP44s1pvr1twFdeb5UZkarBgFZo6WUR7iqz_cZp_1vZE1sfcw@mail.gmail.com","threadId":"31960","inReplyTo":"c0f8d214-4d61-4b02-8bda-4f26c33ae30f@email.android.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T02:54:19Z","receivedAt":"2012-11-01T02:54:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 2:41 AM, Junio C Hamano wrote:\n>\n>\n> Johannes Schindelin wrote:\n>\n>>Junio wanted a more general solution, adding infrastructure to the\n>>rev-list engine that I did not need -- and did not see the need for,\n>>either -- and given the amount of time I had invested in a working\n>>remote-hg and given that I needed it desperately for my day-job\n>>project, ...\n>\n> This is relatively long ago (and I am away from my machine, so I cannot check) so I may misremembering things, but my impression is that since that discussion, we added a minimal \"infrastructure\" to the rev-list (I think we caled it rev-list-cmdline or something like that) and Sverre used it to update fast-export.\n>\n> It may well be that what we have is still not sufficient to do everything you need, but it may be close enough to get extended for your original use case.\n\nI don't think there's missing, the following patch works fine:\nhttp://article.gmane.org/gmane.comp.version-control.git/208730\n\nThere's a minute issue, but I think that would require changes in\nfast-export itself and its marks, not rev-list. But nobody would care\nanyway, it's not a problem.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202355","messageId":"CAMP44s2G2MGuPH-UXfoKNOpx0cuSE87Uz=6B-7H1MzJHf6VMjA@mail.gmail.com","threadId":"31960","inReplyTo":"bec4d263-b458-4636-9fa6-1c1202416810@email.android.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T02:58:20Z","receivedAt":"2012-11-01T02:58:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano wrote:\n> Johannes Schindelin wrote:\n>\n>>On Wed, 31 Oct 2012, Felipe Contreras wrote:\n>>\n>>> It doesn't get any more obvious than that. But to each his own.\n>>\n>>In my opinion, Jonathan does not deserve any of such condescending\n>>words.\n>>But maybe the Git maintainers are okay with such a tone on this list?\n>\n> Agreed, and no.\n>\n> We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one.\n\nJust for the record, what exactly is the problem with the above?\n\n1) The fact that I say it's obvious\n2) The fact that I say everyone is entitled to their own opinions\n\nI don't think I said anything else.\n\n-- \nFelipe Contreras\n"},{"id":"202356","messageId":"CAMP44s3UHQE69O__EVK29uN_VPdZN=a0-Gczeh-Tbjp1ZAAbJw@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s0KFJW2F3gbO_Xd9QKrZ1OoxvUCvecU084-zH2UDqXKag@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T04:08:52Z","receivedAt":"2012-11-01T04:08:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Oct 31, 2012 at 8:47 PM, Felipe Contreras\n wrote:\n> On Wed, Oct 31, 2012 at 7:04 PM, Felipe Contreras\n> wrote:\n>\n>> How about performance?\n>\n>> 174.038642915 seconds time elapsed\n>>\n>> Compared to;\n>\n>> 340.976843750 seconds time elapsed\n>>\n>> Looks like there's something to improve in this area, but I wouldn't\n>> be surprised if the reason for the better performance is that\n>> something is not being done. I'll investigate.\n>\n> Turns out msysgit's remote-hg is not exporting the whole repository,\n> that's why it's faster =/\n\nIt seems the reason is that it would only export to the point where\nthe branch is checked out. After updating the to the tip I noticed\nthere was a performance difference.\n\nI investigated and found two reasons:\n\n1) msysgit's version doesn't export files twice, I've now implemented the same\n2) msysgit's version uses a very simple algorithm to find out file changes\n\nThis second point causes msysgit to miss some file changes. Using the\nsame algorithm I get the same performance, but the output is not\ncorrect.\n\nHere's after the latest updates:\n\n Performance counter stats for 'git clone hg::~/dev/hg-clean hg-clean-5':\n\n 288338.286545 task-clock # 1.299 CPUs utilized\n 46,441 context-switches # 0.161 K/sec\n 6,098 CPU-migrations # 0.021 K/sec\n 509,600 page-faults # 0.002 M/sec\n 518,370,729,897 cycles # 1.798 GHz\n 204,476,102,906 stalled-cycles-frontend # 39.45% frontend cycles idle\n stalled-cycles-backend\n 726,005,034,102 instructions # 1.40 insns per cycle\n # 0.28 stalled cycles per insn\n 127,662,400,651 branches # 442.752 M/sec\n 6,758,976,722 branch-misses # 5.29% of all branches\n\n 222.020233009 seconds time elapsed\n\nWhich is taking roughly 60% more time than msysgit, but the output is\nactually correct.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202365","messageId":"50927D29.3020703@lsrfire.ath.cx","threadId":"31960","inReplyTo":"CAMP44s2G2MGuPH-UXfoKNOpx0cuSE87Uz=6B-7H1MzJHf6VMjA@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2012-11-01T13:46:17Z","receivedAt":"2012-11-01T13:46:17Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 01.11.2012 03:58, schrieb Felipe Contreras:\n> On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano wrote:\n>> Johannes Schindelin wrote:\n>>\n>>> On Wed, 31 Oct 2012, Felipe Contreras wrote:\n>>>\n>>>> It doesn't get any more obvious than that. But to each his own.\n>>>\n>>> In my opinion, Jonathan does not deserve any of such condescending\n>>> words.\n>>> But maybe the Git maintainers are okay with such a tone on this list?\n>>\n>> Agreed, and no.\n>>\n>> We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one.\n>\n> Just for the record, what exactly is the problem with the above?\n>\n> 1) The fact that I say it's obvious\n> 2) The fact that I say everyone is entitled to their own opinions\n\nObviousness is in the eye of the beholder. This is a fact that I tend \nto forget just too easily as well.\n\nYou probably didn't intend it, but your sentences at the top can be read \nmore like: \"This is a logical consequence. If you don't understand \nthat, your mental capabilities must be lacking.\". That's obviously \n(ha!) a rude thing to say.\n\nAlso, and I'm sure you didn't know that, \"Jedem das Seine\" (to each his \nown) was the slogan of the Buchenwald concentration camp. For that \nreason some (including me) hear the unspoken cynical half-sentence \"and \nsome people just have to be sent to the gas chamber\" when someone uses \nthis proverb.\n\nNo accusations intended, just trying to answer your question from my \npoint of view.\n\nRené\n"},{"id":"202366","messageId":"CAPabhsKV6GM92J5vib9d79DW3LDXeS40s+-M5OHBKmfXGezaOQ@mail.gmail.com","threadId":"31960","inReplyTo":"50927D29.3020703@lsrfire.ath.cx","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2012-11-01T14:18:04Z","receivedAt":"2012-11-01T14:18:04Z","isPatch":true,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe\n wrote:\n> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each his own)\n> was the slogan of the Buchenwald concentration camp. For that reason some\n> (including me) hear the unspoken cynical half-sentence \"and some people just\n> have to be sent to the gas chamber\" when someone uses this proverb.\n\nGodwin's Law. That went fast, just one day :)\n"},{"id":"202367","messageId":"CACPiFCKHpHPL9jGgqhEAGyK=K8UyytUUe9z6D7P1RzFPB-8q0w@mail.gmail.com","threadId":"31960","inReplyTo":"50927D29.3020703@lsrfire.ath.cx","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2012-11-01T14:18:07Z","receivedAt":"2012-11-01T14:18:07Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe\n wrote:\n> You probably didn't intend it, but your sentences at the top can be read\n> more like: \"This is a logical consequence. If you don't understand that,\n> your mental capabilities must be lacking.\". That's obviously (ha!) a rude\n> thing to say.\n\n+1\n\n> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each his own)\n\nOuch! I sure didn't know that. Thanks for that tidbit. Working with\npeople from all over the world always teaches me that I might be\nsaying the wrong thing... accidentally. And to be tolerant of others'\nsayings.\n\n{ To dispel any confusion, no, I am not German. I'm from a big\nmelting-pot of peoples :-) }\n\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"202368","messageId":"CAMP44s0TVQOKc=Ce_k1DTwZHuPUmroOaVMPg4t--bmt=3fDPuQ@mail.gmail.com","threadId":"31960","inReplyTo":"50927D29.3020703@lsrfire.ath.cx","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T14:34:57Z","receivedAt":"2012-11-01T14:34:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 2:46 PM, René Scharfe\n wrote:\n> Am 01.11.2012 03:58, schrieb Felipe Contreras:\n>\n>> On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano wrote:\n>>>\n>>> Johannes Schindelin wrote:\n>>>\n>>>> On Wed, 31 Oct 2012, Felipe Contreras wrote:\n>>>>\n>>>>> It doesn't get any more obvious than that. But to each his own.\n>>>>\n>>>>\n>>>> In my opinion, Jonathan does not deserve any of such condescending\n>>>> words.\n>>>> But maybe the Git maintainers are okay with such a tone on this list?\n>>>\n>>>\n>>> Agreed, and no.\n>>>\n>>> We've been hoping we can do without a rigid code of conduct written down\n>>> to maintain cordial community focused on technical merits, and instead\n>>> relied on people's common sense, but sense may not be so common,\n>>> unfortunately, so we may have to have one.\n>>\n>>\n>> Just for the record, what exactly is the problem with the above?\n>>\n>> 1) The fact that I say it's obvious\n>> 2) The fact that I say everyone is entitled to their own opinions\n>\n>\n> Obviousness is in the eye of the beholder.\n\nSometimes. Other times things are obviously obvious, not for the\nperson uttering the words, but for everyone. But I agree that others\nwould disagree, which is why I followed that sentence to one making\nsure that I understand that there's a disagreement.\n\n> This is a fact that I tend to forget just too easily as well.\n\nI didn't.\n\nAnd even if I did, what is the problem with saying \"this is obvious\"?\n\n> You probably didn't intend it, but your sentences at the top can be read\n> more like: \"This is a logical consequence. If you don't understand that,\n> your mental capabilities must be lacking.\". That's obviously (ha!) a rude\n> thing to say.\n\nPeople can read things in many ways. If you need to pass every\nsentence you write in a *technical* mailing list through a public\nrelation professional, well, the throughput of such mailing list is\ngoing to suffer.\n\nThat being said, I did wonder what must be going through his mind to\nnot see that as obvious, but I did NOT *say* anything offensive.\nSpecially because I know people have different perspectives, and the\nfact that a perspective doesn't allow you to see something obvious\ndoesn't say anything about your mental capabilities, only about your\nperspectives, biases, or even current mental state. Who knows, maybe\nyou skipped your coffee.\n\nTo assume otherwise is reading too much into things. Read what is\nbeing said, and nothing more. Don't make assumptions.\n\nAnd a guideline I love from Wikipedia: Always assume *good faith*.\nSometimes, of course, even if you assume good faith things are\noffensive. This is not the case here.\n\n> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each his own)\n> was the slogan of the Buchenwald concentration camp.\n\nNo, I don't know, and frankly, I don't care.\n\nCultural differences go both ways. You need to assume that whatever\ncultural reference you are thinking of, might not be the same for the\nother person. Again: assume *good faith*.\n\nAnd in English, and probably most Latin language countries, \"to each\nhis own\" is pretty well understood:\n\nhttp://en.wiktionary.org/wiki/to_each_his_own\n\nEtymology\nA calque of Latin suum cuique, short for suum cuique pulchrum est (“to\neach his own is beautiful”).\n\nProverb\nto each his own\nEvery person is entitled to his or her personal preferences and tastes.\nI would never want my bathroom decorated in chartreuse and turquoise,\nbut to each his own, I suppose.\n\nSynonyms\nthere's no accounting for taste\n\n> For that reason some\n> (including me) hear the unspoken cynical half-sentence \"and some people just\n> have to be sent to the gas chamber\" when someone uses this proverb.\n\nI never said anything of the sort, and assuming otherwise is a mistake.\n\nIf you always assume bad faith you will inevitably get offended by\nthings that were never meant to be offensive. It's not a good\nguideline.\n\n> No accusations intended, just trying to answer your question from my point\n> of view.\n\nThanks, but I think if others are thinking along the same lines, this\nis not good. Following the guideline of always assuming good faith\nmakes it easier for people to communicate, and people not getting hurt\nwhen in fact no offense was intended, which it turns out to be most of\nthe time.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202369","messageId":"CACPiFCJ2z38jTwrFpQQC08184JB5XkQ4q5c=yXvuGonY5WYKpQ@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s0TVQOKc=Ce_k1DTwZHuPUmroOaVMPg4t--bmt=3fDPuQ@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2012-11-01T14:47:41Z","receivedAt":"2012-11-01T14:47:41Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Felipe,\n\nI'll invite you to reread some of your words:\n\n> That being said, I did wonder what must be going through his mind to\n> not see that as obvious,\n(...)\n\n> Following the guideline of always assuming good faith\n\nSo perhaps it does apply that you could try to assume good\nintellectual faith in others. When you wonder \"what must be going\nthrough his mind to not see it as obvious\"... you should consider\n\"hey, maybe I am missing some aspect of this\".\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"202372","messageId":"CAMP44s01bsgjbjm1m=Md-tvt=12Mw-8VOSSt+TOUNWKJkuzPUQ@mail.gmail.com","threadId":"31960","inReplyTo":"CACPiFCJ2z38jTwrFpQQC08184JB5XkQ4q5c=yXvuGonY5WYKpQ@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-01T17:13:15Z","receivedAt":"2012-11-01T17:13:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 1, 2012 at 3:47 PM, Martin Langhoff\n wrote:\n> Felipe,\n>\n> I'll invite you to reread some of your words:\n>\n>> That being said, I did wonder what must be going through his mind to\n>> not see that as obvious,\n> (...)\n>\n>> Following the guideline of always assuming good faith\n>\n> So perhaps it does apply that you could try to assume good\n> intellectual faith in others. When you wonder \"what must be going\n> through his mind to not see it as obvious\"... you should consider\n> \"hey, maybe I am missing some aspect of this\".\n\nThat's what I did.\n\nBut even if I didn't, that's not offensive, that only means I made a\nmistake and it is actually not obvious. But that would be a\n*technical* mistake.\n\nWhen I feel something is obvious, I say \"I think this is obvious\",\nwhen I feel something is obvious to me, but not to others, I say \"This\nis obvious to me\", when I believe with every fiber of my being that\nsomething is obvious with a very low margin of error, not only to me,\nbut to other people, I say \"this is as obvious as it gets\". Of course,\nthere's the possibility that I missed something, there's always that\npossibility, but even if I did, that would be a *technical* mistake.\n\nIf you want to discuss the technical aspect of whether or not that is\nobvious, feel free to comment in the other thread. This one is about\nnetiquette. And I've yet to see what is wrong with saying \"this is\nobvious\", *specially* if we are assuming good faith from both sides,\nand both sides have already agreed that there's a disagreement, no\ninsults, no name calling, not ad hominem attacks; simply a\ndisagreement. Nothing wrong with disagreeing, even if it's strongly.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202377","messageId":"20121101204625.GC6213@elie.Belkin","threadId":"31960","inReplyTo":"bec4d263-b458-4636-9fa6-1c1202416810@email.android.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-11-01T20:46:25Z","receivedAt":"2012-11-01T20:46:25Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> We've been hoping we can do without a rigid code of conduct written\n> down to maintain cordial community focused on technical merits, and\n> instead relied on people's common sense, but sense may not be so\n> common, unfortunately, so we may have to have one.\n\nI think that except for occasional lapses this list stays pretty close\nto what, for example, the Fedora[1] and Ubuntu[2] codes of conduct\nrequire, and what Emily Postnews's guide[3] explains not to do.\n\nWhat's the next step?\n\n[1] http://www.ubuntu.com/project/about-ubuntu/conduct\n[2] http://www.ubuntu.com/project/about-ubuntu/conduct\n[3] http://www.templetons.com/brad/emily.html\n"},{"id":"202402","messageId":"5093949D.4070509@op5.se","threadId":"31960","inReplyTo":"50927D29.3020703@lsrfire.ath.cx","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-11-02T09:38:37Z","receivedAt":"2012-11-02T09:38:37Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 11/01/2012 02:46 PM, René Scharfe wrote:\n> \n> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each\n> his own) was the slogan of the Buchenwald concentration camp. For\n> that reason some (including me) hear the unspoken cynical\n> half-sentence \"and some people just have to be sent to the gas\n> chamber\" when someone uses this proverb.\n> \n\nIt goes further back than that.\n\n\"Suum cuique pulchrum est\" (\"To each his own is a beautiful thing\") is\na latin phrase said to be used frequently in the roman senate when\nsenators politely agreed to disagree and let a vote decide the outcome\nrather than debating further.\n\nPlease don't let the twisted views of whatever nazi idiot thought it\nmeant \"you may have the wrong faith and therefore deserve to die, so you\nshall\" pollute it. The original meaning is both poetic and democratic,\nand I firmly believe most people have the original meaning to the fore\nof their mind when using it. After all, very few people knowingly quote\nnazi concentration camp slogans.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"202410","messageId":"5093A873.9090701@drmicha.warpmail.net","threadId":"31960","inReplyTo":"5093949D.4070509@op5.se","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-02T11:03:15Z","receivedAt":"2012-11-02T11:03:15Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:\n> On 11/01/2012 02:46 PM, René Scharfe wrote:\n>>\n>> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each\n>> his own) was the slogan of the Buchenwald concentration camp. For\n>> that reason some (including me) hear the unspoken cynical\n>> half-sentence \"and some people just have to be sent to the gas\n>> chamber\" when someone uses this proverb.\n>>\n> \n> It goes further back than that.\n> \n> \"Suum cuique pulchrum est\" (\"To each his own is a beautiful thing\") is\n> a latin phrase said to be used frequently in the roman senate when\n> senators politely agreed to disagree and let a vote decide the outcome\n> rather than debating further.\n> \n> Please don't let the twisted views of whatever nazi idiot thought it\n> meant \"you may have the wrong faith and therefore deserve to die, so you\n> shall\" pollute it. The original meaning is both poetic and democratic,\n> and I firmly believe most people have the original meaning to the fore\n> of their mind when using it. After all, very few people knowingly quote\n> nazi concentration camp slogans.\n>\n\nIn fact, many German terms and words are \"forbidden area\" since Nazi\ntimes, but I don't think this one carries the same connotation.\n\nBut that is a side track.\n\nCollaboration (and code review is a form of collaboration) requires\ncommunication. The linked code of conduct pages describe quite well how\nto ensure a productive environment in which \"everyone\" feels comfortable\ncommunicating and collaborating. But even reading pages like these\nrequires a common sense (of the many undefined terms therein), a sense\nwhich is usually present here on the list, and thus renders a page like\nthese unnecessary for us. Once there is a lack of commonality, there is\na lack of agreement about those undefined terms (what constitutes a\npersonal attack etc.).\n\nConsequently, the only practical test for commonality and community\nacceptance appears to be just that: commonality and community\nacceptance. If many people in a community consider a tone or formulation\noffensive, then it is offensive by the very definition of common sense\n(common to that community), and there's no point at all in arguing about\nit. If I don't like a community's sense I either deal with it or leave it.\n\nIt's really not that different from coding style. If we prefer\n\nif (cond) {\n\nover\n\nif (cond)\n{\n\nthen you either do it that way or your code gets rejected. The\ndifference is that coding style is easier to define, of course. The\ncommon thing is that there's no point in arguing about it.\n\nMichael\n"},{"id":"202428","messageId":"20121102144618.GA11170@sigill.intra.peff.net","threadId":"31960","inReplyTo":"CAMP44s2PDZwTW55NDho9DyB2XZmsG0-KH4e78grJ2OFRVZkfjg@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-02T14:46:18Z","receivedAt":"2012-11-02T14:46:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2012 at 05:11:39PM +0100, Felipe Contreras wrote:\n\n> > As a patch\n> > submitter, you (\"generic you\") want the attention of others as\n> > reviewers. It's in your own (again \"generic you\") interest not to put\n> > them off, in the same way as it's up to the submitter to argue why a\n> > patch is desirable and correct.\n> \n> Ah, so you are making me a favor by reviewing the code?\n\nI do not want to get embroiled in a discussion of manners and netiquette\n(or, for that matter, nazis). But I think this point is worth calling\nattention to, because it seems to be at the crux of the matter.\n\nBasically, my opinion is that yes, he is doing a favor to you by\nreviewing the code. Just as you have done us a favor by submitting the\ncode. And this is not specific to this topic or to you as a submitter.\nIt is a part of how the open source process works.\n\nWe have an existing code base that works well. It certainly has some\nbugs, and it certainly is missing some features. But people use it every\nday and are happy. The maintainers of that code base would want it to\nimprove over time, but they would also have to be careful not to\nintroduce regressions. And not just specific regressions in behavior; I\nmean regressions in overall quality. A half-implemented feature that\ncrashes is worse than no feature at all. A change that fixes one bug but\nhurts the readability of the code, leading to many future bugs, is a net\nnegative.\n\nSo when a contributor shows up with code, we are very grateful that\nthey've spent their time improving our software. But at the same time,\nwe must recognize that the contributor is generally scratching their own\nitch. And we must make sure that in doing so, they did not hurt other\npeople's use cases, nor regress the overall quality of the code base.\n\nIt is the job of the maintainer to measure the risk and reward of each\nchange and to find a balance in accepting patches. But it's difficult to\ndo alone, and that is why volunteer reviewers on the list are very\nvaluable. They distribute the reviewing load across many brains, and in\nmany cases have expertise in particular areas that the maintainer can\nrely on.\n\nA submitter has scratched their own itch by writing the code. But if\nthey cannot cooperate with reviewers enough to get feedback, then the\nmaintainer has only two choices: review the patches themselves, or\nreject the change. And when there is conflict with the regular reviewers\nand the submitter, it is a red flag to the maintainer that it might not\nbe worth spending a lot of time there.\n\nDoes the code base suffer for this in the end? Perhaps. There are\nfeatures we might reject that could have benefited everybody. But we\nmight also be saving ourselves from the headaches caused by poorly\nthought-out changes. The system cannot work if everybody does not show\nup and cooperate.\n\n\nNow, as for this specific topic: it is proposed for contrib, which means\nthat expectations are lower, and the rest of git does not suffer too\nmuch if it has rough edges. At the same time, it also means that it\ncould live fairly easily outside of the tree. In fact, I think Michael\nand others have been reasonably happy with their own out-of-tree\nimplementation.\n\nI do think the proliferation of various implementations has made it hard\nfor users to see which ones are worth trying. So I think there is value\nin carrying something in contrib/, as it would focus the attention of\nusers, and of other developers to make improvements.\n\nSo I think what I'd like to do is take your latest series into pu, with\nthe intention of merging it into next soon, and then cooking it in next\nfor a while. That would hopefully make it very easy for people following\n'next' to try it out and see how it compares in the field with other\ntools they have used (the msysgit one, or others).\n\nI'm a little worried about hurting progress on the msysgit version; it\nsounds like the functionality of your implementation is at parity with\nthat one (thanks to both you and Johannes for answering my other email\nasking for a summary). Johannes did mention that the design of their\ntool was meant to eventually facilitate more backends. That's something\nthat might be valuable; on the other hand, that development hasn't been\nhappening, and there has been no effort lately on getting it merged into\ngit.git. I don't want to hold working code hostage to a future plan that\nmight or might not happen. So I hope by keeping it in next for a bit,\nthat will give msysgit people time to check it out and mobilize their\nefforts to improve their version if they would like.\n\n-Peff\n"},{"id":"202430","messageId":"20121102144827.GB11170@sigill.intra.peff.net","threadId":"31960","inReplyTo":"CAMP44s3UHQE69O__EVK29uN_VPdZN=a0-Gczeh-Tbjp1ZAAbJw@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-02T14:48:27Z","receivedAt":"2012-11-02T14:48:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:\n\n> > Turns out msysgit's remote-hg is not exporting the whole repository,\n> > that's why it's faster =/\n> \n> It seems the reason is that it would only export to the point where\n> the branch is checked out. After updating the to the tip I noticed\n> there was a performance difference.\n> \n> I investigated and found two reasons:\n> \n> 1) msysgit's version doesn't export files twice, I've now implemented the same\n> 2) msysgit's version uses a very simple algorithm to find out file changes\n> \n> This second point causes msysgit to miss some file changes. Using the\n> same algorithm I get the same performance, but the output is not\n> correct.\n\nDo you have a test case that demonstrates this? It would be helpful for\nreviewers, but also helpful to msysgit people if they want to fix their\nimplementation.\n\n-Peff\n"},{"id":"202447","messageId":"CAMP44s0yk3k1awYbJCcReBDEAjMyfHtKH70S7v2ZOJ1u5OcBAw@mail.gmail.com","threadId":"31960","inReplyTo":"5093A873.9090701@drmicha.warpmail.net","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T16:09:11Z","receivedAt":"2012-11-02T16:09:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber\n wrote:\n> Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:\n>> On 11/01/2012 02:46 PM, René Scharfe wrote:\n>>>\n>>> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each\n>>> his own) was the slogan of the Buchenwald concentration camp. For\n>>> that reason some (including me) hear the unspoken cynical\n>>> half-sentence \"and some people just have to be sent to the gas\n>>> chamber\" when someone uses this proverb.\n>>>\n>>\n>> It goes further back than that.\n>>\n>> \"Suum cuique pulchrum est\" (\"To each his own is a beautiful thing\") is\n>> a latin phrase said to be used frequently in the roman senate when\n>> senators politely agreed to disagree and let a vote decide the outcome\n>> rather than debating further.\n>>\n>> Please don't let the twisted views of whatever nazi idiot thought it\n>> meant \"you may have the wrong faith and therefore deserve to die, so you\n>> shall\" pollute it. The original meaning is both poetic and democratic,\n>> and I firmly believe most people have the original meaning to the fore\n>> of their mind when using it. After all, very few people knowingly quote\n>> nazi concentration camp slogans.\n>>\n>\n> In fact, many German terms and words are \"forbidden area\" since Nazi\n> times, but I don't think this one carries the same connotation.\n>\n> But that is a side track.\n>\n> Collaboration (and code review is a form of collaboration) requires\n> communication. The linked code of conduct pages describe quite well how\n> to ensure a productive environment in which \"everyone\" feels comfortable\n> communicating and collaborating.\n\nYes, but that's assuming we want \"everyone\" to feel comfortable\ncommunicating and collaborating. I cite again the example of the Linux\nkernel, where certainly not \"everyone\" feels that way. But somehow\nthey manage to be perhaps the most successful software project in\nhistory. And I would argue even more: it's _because_ not everyone\nfeels comfortable, it's because ideas and code are criticized freely,\nand because only the ones that do have merit stand. If you are able to\ntake criticism, and you are not emotionally and personally attacked to\nyour code and your ideas, you would thrive in this environment. If you\ndon't want your precious little baby code to fight against the big\nguys, then you shouldn't send it out to the world.\n\nJunio mentioned \"technical merit\", and I believe for that open and\n_honest_ communication is more important than making \"everyone\" feel\ncomfortable.\n\nAnd FWIW I don't feel comfortable expressing my opinion any more,\nbecause even if I criticize ideas and code on a *technical* basis, I'm\nassumed to be referencing Nazism and whatnot without any regards of\nwhat my original intentions were, or what I actually said, and\ndefinitely not assuming good faith. And when asked for clarification\nof what exactly that I said was offensive, I get no clear answer.\n\nThe dangers of \"everyone\" following the same style of communication,\nand making \"everyone\" feel comfortable, is that \"everyone\" ends up\nbeing the same kind of people, and the ones that don't fit the\ndefinition of \"everyone\" feel like outsiders, or outright leave the\nproject. And you end up with an homogeneous group of people incapable\nof criticizing each other honestly (on a technical basis), whether\nit's because of lack of a different perspective, or unwillingness to\nspeak openly, or difficulty in finding the right polite words. I've\nseen many projects fall into this, and erode with time, since nothing\nimportant actually happens, and real deep issues within the code or\nthe community get ignored.\n\nAnyway, I've yet to find what was actually wrong in the words I said.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202451","messageId":"CAMP44s1P5Y_H24=ZKS5n_rUORf1dTiqg3qXm3bHcOiQ8K12PUQ@mail.gmail.com","threadId":"31960","inReplyTo":"20121102144827.GB11170@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T16:41:34Z","receivedAt":"2012-11-02T16:41:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 3:48 PM, Jeff King wrote:\n> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:\n>\n>> > Turns out msysgit's remote-hg is not exporting the whole repository,\n>> > that's why it's faster =/\n>>\n>> It seems the reason is that it would only export to the point where\n>> the branch is checked out. After updating the to the tip I noticed\n>> there was a performance difference.\n>>\n>> I investigated and found two reasons:\n>>\n>> 1) msysgit's version doesn't export files twice, I've now implemented the same\n>> 2) msysgit's version uses a very simple algorithm to find out file changes\n>>\n>> This second point causes msysgit to miss some file changes. Using the\n>> same algorithm I get the same performance, but the output is not\n>> correct.\n>\n> Do you have a test case that demonstrates this? It would be helpful for\n> reviewers, but also helpful to msysgit people if they want to fix their\n> implementation.\n\nCloning the mercurial repo:\n\n% hg log --stat -r 131\nchangeset: 131:c9d51742471c\nparent: 127:44538462d3c8\nuser: jake@edge2.net\ndate: Sat May 21 11:35:26 2005 -0700\nsummary: moving hgweb to mercurial subdir\n\n hgweb.py | 377\n------------------------------------------------------------------------------------------\n mercurial/hgweb.py | 377\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 377 insertions(+), 377 deletions(-)\n\n% git show --stat 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\ncommit 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\nAuthor: jake@edge2.net \nDate: Sat May 21 11:35:26 2005 -0700\n\n moving hgweb to mercurial subdir\n\n mercurial/hgweb.py | 377\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 377 insertions(+)\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202454","messageId":"CAMP44s1mbNBUspJ8SX=VwGSXthxWAHkrQLFRxzyCzkupLYSagA@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s1P5Y_H24=ZKS5n_rUORf1dTiqg3qXm3bHcOiQ8K12PUQ@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T18:01:55Z","receivedAt":"2012-11-02T18:01:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras\n wrote:\n> On Fri, Nov 2, 2012 at 3:48 PM, Jeff King wrote:\n>> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:\n>>\n>>> > Turns out msysgit's remote-hg is not exporting the whole repository,\n>>> > that's why it's faster =/\n>>>\n>>> It seems the reason is that it would only export to the point where\n>>> the branch is checked out. After updating the to the tip I noticed\n>>> there was a performance difference.\n>>>\n>>> I investigated and found two reasons:\n>>>\n>>> 1) msysgit's version doesn't export files twice, I've now implemented the same\n>>> 2) msysgit's version uses a very simple algorithm to find out file changes\n>>>\n>>> This second point causes msysgit to miss some file changes. Using the\n>>> same algorithm I get the same performance, but the output is not\n>>> correct.\n>>\n>> Do you have a test case that demonstrates this? It would be helpful for\n>> reviewers, but also helpful to msysgit people if they want to fix their\n>> implementation.\n>\n> Cloning the mercurial repo:\n>\n> % hg log --stat -r 131\n> changeset: 131:c9d51742471c\n> parent: 127:44538462d3c8\n> user: jake@edge2.net\n> date: Sat May 21 11:35:26 2005 -0700\n> summary: moving hgweb to mercurial subdir\n>\n> hgweb.py | 377\n> ------------------------------------------------------------------------------------------\n> mercurial/hgweb.py | 377\n> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n> 2 files changed, 377 insertions(+), 377 deletions(-)\n>\n> % git show --stat 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\n> commit 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\n> Author: jake@edge2.net \n> Date: Sat May 21 11:35:26 2005 -0700\n>\n> moving hgweb to mercurial subdir\n>\n> mercurial/hgweb.py | 377\n> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 377 insertions(+)\n\nI talked with some people in #mercurial, and apparently there is a\nconcept of a 'changelog' that is supposed to store these changes, but\nsince the format has changed, the content of it is unreliable. That's\nnot a big problem because it's used mostly for reporting purposes\n(log, query), not for doing anything reliable.\n\nTo reliably see the changes, one has to compare the 'manifest' of the\nrevisions involved, which contain *all* the files in them.\n\nThat's what I was doing already, but I found a more efficient way to\ndo it. msysGit is using the changelog, which is quite fast, but not\nreliable.\n\nUnfortunately while going trough mercurial's code, I found an issue,\nand it turns out that 1) is not correct.\n\nIn mercurial, a file hash contains also the parent file nodes, which\nmeans that even if two files have the same content, they would not\nhave the same hash, so there's no point in keeping track of them to\navoid extracting the data unnecessarily, because in order to make sure\nthey are different, you need to extract the data anyway, defeating the\npurpose.\n\nWhich means mercurial doesn't really behave as one would expect:\n\n# add files with the same content\n\n $ echo a > a\n $ hg ci -Am adda\n adding a\n $ echo a >> a\n $ hg ci -m changea\n $ echo a > a\n $ hg st --rev 0\n $ hg ci -m reverta\n $ hg log -G --template '{rev} {desc}\\n'\n @ 2 reverta\n |\n o 1 changea\n |\n o 0 adda\n\n# check the difference between the first and the last revision\n\n $ hg st --rev 0:2\n M a\n $ hg cat -r 0 a\n a\n $ hg cat -r 2 a\n a\n\nI will be checking again from where did I get the performance\nimprovements, but most likely it's from my implementation of\nmercurial's repo.status().\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202455","messageId":"CAMP44s0N3k4b9SoKpkR=2-zSBb41tKW37tYhuxFfbooiLu59Kw@mail.gmail.com","threadId":"31960","inReplyTo":"20121102144618.GA11170@sigill.intra.peff.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T18:39:21Z","receivedAt":"2012-11-02T18:39:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 3:46 PM, Jeff King wrote:\n> On Wed, Oct 31, 2012 at 05:11:39PM +0100, Felipe Contreras wrote:\n>\n>> > As a patch\n>> > submitter, you (\"generic you\") want the attention of others as\n>> > reviewers. It's in your own (again \"generic you\") interest not to put\n>> > them off, in the same way as it's up to the submitter to argue why a\n>> > patch is desirable and correct.\n>>\n>> Ah, so you are making me a favor by reviewing the code?\n>\n> I do not want to get embroiled in a discussion of manners and netiquette\n> (or, for that matter, nazis). But I think this point is worth calling\n> attention to, because it seems to be at the crux of the matter.\n>\n> Basically, my opinion is that yes, he is doing a favor to you by\n> reviewing the code. Just as you have done us a favor by submitting the\n> code.\n\nWho cares about _us_? What is important is the bigger picture, git,\nthe project, and its users.\n\nYes, some people might think only about themselves, and that's their\nchoice, but I don't think us (the git project) should worry about\nmaking me favors, only about improving the project.\n\n> And this is not specific to this topic or to you as a submitter.\n> It is a part of how the open source process works.\n\nI disagree. The open source process works not by making favors to each\nother, but by everyone sharing and improving the code, by\n*collaborating*. \"I review your code if you review mine\", or \"if you\nby me a bear in the next conference\" is not the spirit of open source,\nalthough it might happen often.\n\n> We have an existing code base that works well. It certainly has some\n> bugs, and it certainly is missing some features. But people use it every\n> day and are happy. The maintainers of that code base would want it to\n> improve over time, but they would also have to be careful not to\n> introduce regressions. And not just specific regressions in behavior; I\n> mean regressions in overall quality. A half-implemented feature that\n> crashes is worse than no feature at all. A change that fixes one bug but\n> hurts the readability of the code, leading to many future bugs, is a net\n> negative.\n\nIndeed, but that has nothing to do with _us_ making _us_ favors, this\nis about the *project*.\n\nAnd having said that, this particular remote-hg helper is meant for\nthe *contrib* area, it's not half-implemented at all, and it's\ncertainly not crashing, or at least nobody has shown any evidence of\nthat. And for that matter, I'm sure I can point out to code that sits\nin contrib that does meat that criteria (it's half-implemented, and\nmight even crash).\n\nI know that you didn't mean otherwise, but in the context of\nremote-hg, this seems hardly relevant.\n\nAnd even if this wasn't for contrib, and this was half-implemented,\nand this crashed... he still wouldn't be making _me_ any favors. The\nreview is for the project, not for me.\n\n> So when a contributor shows up with code, we are very grateful that\n> they've spent their time improving our software. But at the same time,\n> we must recognize that the contributor is generally scratching their own\n> itch. And we must make sure that in doing so, they did not hurt other\n> people's use cases, nor regress the overall quality of the code base.\n\nI fail to see how any code sitting in 'contrib/remote-hg' could do any of that.\n\n> It is the job of the maintainer to measure the risk and reward of each\n> change and to find a balance in accepting patches. But it's difficult to\n> do alone, and that is why volunteer reviewers on the list are very\n> valuable. They distribute the reviewing load across many brains, and in\n> many cases have expertise in particular areas that the maintainer can\n> rely on.\n\nYes, that is helpful, _for the project_.\n\n> A submitter has scratched their own itch by writing the code. But if\n> they cannot cooperate with reviewers enough to get feedback, then the\n> maintainer has only two choices: review the patches themselves, or\n> reject the change. And when there is conflict with the regular reviewers\n> and the submitter, it is a red flag to the maintainer that it might not\n> be worth spending a lot of time there.\n\nThat would be unfortunate, _for the project_, not for the submitter. I\ncan still run the code, and I can still share it on github.\n\nReviewers wouldn't be making _me_ any favors. It's the project that\nbenefits, and it's for the project that they should do it, or for\nthemselves, not for me.\n\n> Does the code base suffer for this in the end? Perhaps. There are\n> features we might reject that could have benefited everybody. But we\n> might also be saving ourselves from the headaches caused by poorly\n> thought-out changes. The system cannot work if everybody does not show\n> up and cooperate.\n\nMaybe, but most probably not. Take a look at this example:\n\n% git log --oneline contrib/hg-to-git\n44211e8 Correct references to /usr/bin/python which does not exist on FreeBSD\n0def5b6 hg-to-git: fix COMMITTER type-o\nb0c051d hg-to-git: don't import the unused popen2 module\naf9a01e hg-to-git: use git init instead of git init-db\n96f2395 hg-to-git: rewrite \"git-frotz\" to \"git frotz\"\n2553ede hg-to-git: abort if the project directory is not a hg repo\n6376cff hg-to-git: avoid raising a string exception\n37a12dd hg-to-git: add --verbose option\n13bf1a9 hg-to-git: fix parent analysis\n1bc7c13 hg-to-git: improve popen calls\n90e0653 hg-to-git: handle an empty dir in hg.\n7c0d741 hg-to-git speedup through selectable repack intervals\n98d47d4 Add hg-to-git conversion utility.\n\nIs this fully implemented? Is this not crashing? Is the people\ninvolved showing up and cooperating?\n\nIt doesn't look like that, yet, it has not given you any headaches,\nprobably because it's segregated in the contrib area, which what I\nhave tried to do with my patches. _Precisely_ to minimize possible\nheadaches.\n\nPerhaps this is a case of double standards.\n\n> Now, as for this specific topic: it is proposed for contrib, which means\n> that expectations are lower, and the rest of git does not suffer too\n> much if it has rough edges. At the same time, it also means that it\n> could live fairly easily outside of the tree. In fact, I think Michael\n> and others have been reasonably happy with their own out-of-tree\n> implementation.\n\nIt certainly could... to the detriment of the project.\n\n> I do think the proliferation of various implementations has made it hard\n> for users to see which ones are worth trying. So I think there is value\n> in carrying something in contrib/, as it would focus the attention of\n> users, and of other developers to make improvements.\n>\n> So I think what I'd like to do is take your latest series into pu, with\n> the intention of merging it into next soon, and then cooking it in next\n> for a while. That would hopefully make it very easy for people following\n> 'next' to try it out and see how it compares in the field with other\n> tools they have used (the msysgit one, or others).\n\nExcellent! I do agree that this would make it easier for everybody:\nusers to try it, developers to contribute, and keep track of the\nchanges, etc.\n\n> I'm a little worried about hurting progress on the msysgit version; it\n> sounds like the functionality of your implementation is at parity with\n> that one (thanks to both you and Johannes for answering my other email\n> asking for a summary). Johannes did mention that the design of their\n> tool was meant to eventually facilitate more backends. That's something\n> that might be valuable; on the other hand, that development hasn't been\n> happening, and there has been no effort lately on getting it merged into\n> git.git. I don't want to hold working code hostage to a future plan that\n> might or might not happen. So I hope by keeping it in next for a bit,\n> that will give msysgit people time to check it out and mobilize their\n> efforts to improve their version if they would like.\n\nFair enough. I do think my version would facilitate more backends\nbecause the code is very simple and it should be easy to see what you\nneed to change, and you don't need to get familiarized with any\nframework, or classes of classes, and so on. I also think that if\nneeded, I could come up with such a framework as well, and the\nresulting framework would be much simpler.\n\nAs a rule, I don't see much value in writing a framework that works\nonly for one case, that smells more like over-engineering. If we had\ntwo cases (hg and bzr), then we might be able to know with a modicum\nof certainty what such a framework should have. So I would prefer to\nhave two standalone remote-helpers, and _then_ do a framework to\nsimplify both, but not before. But that's my personal opinion.\n\nNow that I have free time, I might be able to spend time writing such\na proof-of-concept remote-bzr, and a simple framework. But I would be\nconcentrated on remote-hg.\n\nThat would be the last one of the supposed advantages of the msysGit\nremote-hg approach, and I make emphasis on supposed because we don't\nknow _for sure_ if the current framework would be useful for a\nremote-bzr or not, *not* because I'm trying to offend anybody (in case\nanybody is thinking that). Hopefully that would show the people that\nhave been working on this other tool that there is indeed value in\nthis code, put aside their personal differences and work together _for\nthe project_, but I wouldn't be holding my breath.\n\nBut to me _first_ what is important is to provide the functionality to\nusers, and _then_ is how we organize the code to make life easier for\nus (the project).\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202456","messageId":"CAMP44s0DyiH+ac-xnfmJ3+JSib+y8GYZZymM83HUjKi5CuqARg@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s0N3k4b9SoKpkR=2-zSBb41tKW37tYhuxFfbooiLu59Kw@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T19:20:28Z","receivedAt":"2012-11-02T19:20:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 7:39 PM, Felipe Contreras\n wrote:\n\n> As a rule, I don't see much value in writing a framework that works\n> only for one case, that smells more like over-engineering. If we had\n> two cases (hg and bzr), then we might be able to know with a modicum\n> of certainty what such a framework should have. So I would prefer to\n> have two standalone remote-helpers, and _then_ do a framework to\n> simplify both, but not before. But that's my personal opinion.\n>\n> Now that I have free time, I might be able to spend time writing such\n> a proof-of-concept remote-bzr, and a simple framework. But I would be\n> concentrated on remote-hg.\n\nActually, there's no point in that; there's already a git-remote-bzr:\n\nhttp://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/git-remote-bzr\n\nSo, what do we need a python framework for?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202461","messageId":"CA+39Oz7vbAwQSfL0PMjjYgQ=njQpu5i_3BSTCzznQJozKOKeXQ@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s0N3k4b9SoKpkR=2-zSBb41tKW37tYhuxFfbooiLu59Kw@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2012-11-02T23:18:15Z","receivedAt":"2012-11-02T23:18:15Z","isPatch":true,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"On 2 November 2012 18:39, Felipe Contreras wrote:\n> I disagree. The open source process works not by making favors to each\n> other, but by everyone sharing and improving the code, by\n> *collaborating*. \"I review your code if you review mine\", or \"if you\n> by me a bear in the next conference\" is not the spirit of open source,\n> although it might happen often.\n\nSo shunning any attempt at explanation, and peddling your own thoughts\nover and over again, irrespective of whether you contribute code or\nnot -- doesn't mean to say you're right, Felipe. And that's the\nfundamental issue here -- your code speaks for itself, sure, no one\ndenies that, but the code is not even *half* of what makes up the\ndiscussion. And so far, the surrounding context and attitude from you\ndoesn't help or enhance the process under which your code is reviewed.\n And no, you cannot philosophise this, or wriggle out of it through\nidealism or some other \"charter\" or \"code of conduct\" -- as reviewers\nof your code, we have to interact with you to be able to better it.\nBut you seem very reluctant to do that.\n\nThe fact that we're even having the conversation is evident of that.\n\n-- Thomas Adam\n"},{"id":"202462","messageId":"CAMP44s2aCpYWzemMCpYJBvT0u4MDNxXge-MOCt=JV+zjyZp-3Q@mail.gmail.com","threadId":"31960","inReplyTo":"CA+39Oz7vbAwQSfL0PMjjYgQ=njQpu5i_3BSTCzznQJozKOKeXQ@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-02T23:52:19Z","receivedAt":"2012-11-02T23:52:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Nov 3, 2012 at 12:18 AM, Thomas Adam wrote:\n> On 2 November 2012 18:39, Felipe Contreras wrote:\n>> I disagree. The open source process works not by making favors to each\n>> other, but by everyone sharing and improving the code, by\n>> *collaborating*. \"I review your code if you review mine\", or \"if you\n>> by me a bear in the next conference\" is not the spirit of open source,\n>> although it might happen often.\n>\n> So shunning any attempt at explanation, and peddling your own thoughts\n> over and over again, irrespective of whether you contribute code or\n> not -- doesn't mean to say you're right, Felipe.\n\nWho is saying I'm right? Certainly not me.\n\nI have explained patches over and over, even to the point that people\napparently get offended, and now you say I should explain more?\n\nI'm sorry, but no, you cannot have your cake and eat it at the same\ntime. Either you want me to explain things, or not.\n\n> And that's the\n> fundamental issue here -- your code speaks for itself, sure, no one\n> denies that, but the code is not even *half* of what makes up the\n> discussion. And so far, the surrounding context and attitude from you\n> doesn't help or enhance the process under which your code is reviewed.\n\nI would say it's the other way around, it's the attitude of other\npeople that believe they are entitled to their opinion not being\nshined in a critical fashion, while at the same time being very\ncritical themselves.\n\nIf you want to disagree, fine, but it's still the project that gets\nhurt, not me, reviewing code is still for the benefit of the project.\n\n> And no, you cannot philosophise this, or wriggle out of it through\n> idealism or some other \"charter\" or \"code of conduct\" -- as reviewers\n> of your code, we have to interact with you to be able to better it.\n\nThat's right, for the benefit of the project.\n\n> But you seem very reluctant to do that.\n\nReluctant to what? Interact? I've answered every single question, and\nthen some. I've also implemented tests, and addressed every criticism\nof this patch series however rude that criticism was thrown.\n\nIt's actually the other way around. There's a thread about netiquette,\nprecisely to avoid certain kinds of discussion.\n\nShow me a *single* instance where I've ignored a review comment, or\nwhatever you mean by being reluctant to interact.\n\n> The fact that we're even having the conversation is evident of that.\n\nThe fact that the sun raised at east and set at the west was evident\nthat it was rotating around the Earth, but that, like many other\nassumptions, was wrong.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202495","messageId":"CAMP44s0wJPqKBVyS-npe7uNEO3EBPH_xUVvzzWd4wCua4gxp9Q@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s0DyiH+ac-xnfmJ3+JSib+y8GYZZymM83HUjKi5CuqARg@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-04T02:28:47Z","receivedAt":"2012-11-04T02:28:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 2, 2012 at 8:20 PM, Felipe Contreras\n wrote:\n> On Fri, Nov 2, 2012 at 7:39 PM, Felipe Contreras\n> wrote:\n>\n>> As a rule, I don't see much value in writing a framework that works\n>> only for one case, that smells more like over-engineering. If we had\n>> two cases (hg and bzr), then we might be able to know with a modicum\n>> of certainty what such a framework should have. So I would prefer to\n>> have two standalone remote-helpers, and _then_ do a framework to\n>> simplify both, but not before. But that's my personal opinion.\n>>\n>> Now that I have free time, I might be able to spend time writing such\n>> a proof-of-concept remote-bzr, and a simple framework. But I would be\n>> concentrated on remote-hg.\n>\n> Actually, there's no point in that; there's already a git-remote-bzr:\n>\n> http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/git-remote-bzr\n\nTurns out the quality of that tools is not that great, so I decided to\nwrite a simple one using bzr-fastimport. It works nicely, although I\nwouldn't trust the quality of bzr-fastimport too much.\n\nIt's so simple I don't see the need of a framework, but if needed, one\ncould be done taking these git-remote-{hg,bzr} as a basis.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202538","messageId":"5097860E.5040607@drmicha.warpmail.net","threadId":"31960","inReplyTo":"CAMP44s0yk3k1awYbJCcReBDEAjMyfHtKH70S7v2ZOJ1u5OcBAw@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-05T09:25:34Z","receivedAt":"2012-11-05T09:25:34Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:\n> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber\n> wrote:\n>> Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:\n>>> On 11/01/2012 02:46 PM, René Scharfe wrote:\n>>>>\n>>>> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each\n>>>> his own) was the slogan of the Buchenwald concentration camp. For\n>>>> that reason some (including me) hear the unspoken cynical\n>>>> half-sentence \"and some people just have to be sent to the gas\n>>>> chamber\" when someone uses this proverb.\n>>>>\n>>>\n>>> It goes further back than that.\n>>>\n>>> \"Suum cuique pulchrum est\" (\"To each his own is a beautiful thing\") is\n>>> a latin phrase said to be used frequently in the roman senate when\n>>> senators politely agreed to disagree and let a vote decide the outcome\n>>> rather than debating further.\n>>>\n>>> Please don't let the twisted views of whatever nazi idiot thought it\n>>> meant \"you may have the wrong faith and therefore deserve to die, so you\n>>> shall\" pollute it. The original meaning is both poetic and democratic,\n>>> and I firmly believe most people have the original meaning to the fore\n>>> of their mind when using it. After all, very few people knowingly quote\n>>> nazi concentration camp slogans.\n>>>\n>>\n>> In fact, many German terms and words are \"forbidden area\" since Nazi\n>> times, but I don't think this one carries the same connotation.\n>>\n>> But that is a side track.\n>>\n>> Collaboration (and code review is a form of collaboration) requires\n>> communication. The linked code of conduct pages describe quite well how\n>> to ensure a productive environment in which \"everyone\" feels comfortable\n>> communicating and collaborating.\n> \n> Yes, but that's assuming we want \"everyone\" to feel comfortable\n> communicating and collaborating.\n\nI put \"everyone\" in quotes because you can never reach 100%, so\n\"everyone\" means almost everyone.\n\nUndeniably, the answers in this and the other threads show that on the\ngit mailing list, \"everyone\" wants \"everyone\" to feel comfortable\ncommunicating and collaborating.\n\n> I cite again the example of the Linux\n> kernel, where certainly not \"everyone\" feels that way. But somehow\n\nIt's a different list with different standards and tone, so it doesn't\nreally matter for our list. That being said:\n\n> they manage to be perhaps the most successful software project in\n> history. And I would argue even more: it's _because_ not everyone\n> feels comfortable, it's because ideas and code are criticized freely,\n> and because only the ones that do have merit stand. If you are able to\n> take criticism, and you are not emotionally and personally attacked to\n> your code and your ideas, you would thrive in this environment. If you\n> don't want your precious little baby code to fight against the big\n> guys, then you shouldn't send it out to the world.\n\nFor one thing, contributors on the kernel list are open to technical\narguments, and that includes the arguments of others; just like we are\nhere. On the other hand, you seem to rebuke \"any\" (most) technical\nargument in harsh words as if it were a personal attack; at least that's\nhow your answers come across to me (and apparently others). That really\nmakes it difficult for most of us here to argue with you technically,\nwhich is a pity. That lack of openness for the arguments of others would\nmake your life difficult on the kernel list also.\n\nA completely different issue is that of language. You talk German on a\nGerman list and English on an international list. You talk \"kernel\nEnglish\" on the kernel list, which is full of words and phrases you\nwould never use in a normal social setting where you talk to people in\nperson; it would be completely unacceptable. Here on the Git list, we\nprefer to talk like in a normal, albeit colloquial social setting. If\nyou're open for advice: just imagine talking to the people here in\nperson, to colleagues across your desk, and you have a good guideline.\n\nAnd no, using the same or similar language does not make us the same at\nall. Using the same language is the natural prerequisite for successful\ncommunication.\n\nFelipe, please try to see the efforts many of us are making here in\norder to keep you as a contributor, and reward it by accepting the\nadvice to revise your language: colleague to colleague.\n\nMichael\n"},{"id":"202543","messageId":"5097C970.9010901@drmicha.warpmail.net","threadId":"31960","inReplyTo":"CAMP44s1mbNBUspJ8SX=VwGSXthxWAHkrQLFRxzyCzkupLYSagA@mail.gmail.com","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-05T14:13:04Z","receivedAt":"2012-11-05T14:13:04Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 02.11.2012 19:01:\n> On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras\n> wrote:\n>> On Fri, Nov 2, 2012 at 3:48 PM, Jeff King wrote:\n>>> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:\n>>>\n>>>>> Turns out msysgit's remote-hg is not exporting the whole repository,\n>>>>> that's why it's faster =/\n>>>>\n>>>> It seems the reason is that it would only export to the point where\n>>>> the branch is checked out. After updating the to the tip I noticed\n>>>> there was a performance difference.\n>>>>\n>>>> I investigated and found two reasons:\n>>>>\n>>>> 1) msysgit's version doesn't export files twice, I've now implemented the same\n>>>> 2) msysgit's version uses a very simple algorithm to find out file changes\n>>>>\n>>>> This second point causes msysgit to miss some file changes. Using the\n>>>> same algorithm I get the same performance, but the output is not\n>>>> correct.\n>>>\n>>> Do you have a test case that demonstrates this? It would be helpful for\n>>> reviewers, but also helpful to msysgit people if they want to fix their\n>>> implementation.\n>>\n>> Cloning the mercurial repo:\n>>\n>> % hg log --stat -r 131\n>> changeset: 131:c9d51742471c\n>> parent: 127:44538462d3c8\n>> user: jake@edge2.net\n>> date: Sat May 21 11:35:26 2005 -0700\n>> summary: moving hgweb to mercurial subdir\n>>\n>> hgweb.py | 377\n>> ------------------------------------------------------------------------------------------\n>> mercurial/hgweb.py | 377\n>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>> 2 files changed, 377 insertions(+), 377 deletions(-)\n>>\n>> % git show --stat 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\n>> commit 1f9bcfe7cc3d7af7b4533895181acd316ce172d8\n>> Author: jake@edge2.net \n>> Date: Sat May 21 11:35:26 2005 -0700\n>>\n>> moving hgweb to mercurial subdir\n>>\n>> mercurial/hgweb.py | 377\n>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>> 1 file changed, 377 insertions(+)\n> \n> I talked with some people in #mercurial, and apparently there is a\n> concept of a 'changelog' that is supposed to store these changes, but\n> since the format has changed, the content of it is unreliable. That's\n> not a big problem because it's used mostly for reporting purposes\n> (log, query), not for doing anything reliable.\n\nIs the changelog stored in the repo (i.e. generated by the hg version at\ncommit time) or generated on the fly (i.e. generated by the hg version\nat hand)? See also below.\n\n> To reliably see the changes, one has to compare the 'manifest' of the\n> revisions involved, which contain *all* the files in them.\n\n'manifest' == '(exploded) tree', right? Just making sure my hg fu is not\nsubzero.\n\n> That's what I was doing already, but I found a more efficient way to\n> do it. msysGit is using the changelog, which is quite fast, but not\n> reliable.\n> \n> Unfortunately while going trough mercurial's code, I found an issue,\n> and it turns out that 1) is not correct.\n> \n> In mercurial, a file hash contains also the parent file nodes, which\n> means that even if two files have the same content, they would not\n> have the same hash, so there's no point in keeping track of them to\n> avoid extracting the data unnecessarily, because in order to make sure\n> they are different, you need to extract the data anyway, defeating the\n> purpose.\n\nDo I understand correctly that neither the msysgit version nor yours can\ndetect duplicate blobs (without requesting them) because of that sha1 issue?\n\nI'm really wondering why a file blob hash carries its history along in\nthe sha1. This appears completely strange to gitters (being brain washed\nabout \"content tracking\"), but may be due to hg's extensive use of\ndelta, or really: delta chains (which do have their merit on the server\nside).\n\n> Which means mercurial doesn't really behave as one would expect:\n> \n> # add files with the same content\n> \n> $ echo a > a\n> $ hg ci -Am adda\n> adding a\n> $ echo a >> a\n> $ hg ci -m changea\n> $ echo a > a\n> $ hg st --rev 0\n> $ hg ci -m reverta\n> $ hg log -G --template '{rev} {desc}\\n'\n> @ 2 reverta\n> |\n> o 1 changea\n> |\n> o 0 adda\n> \n> # check the difference between the first and the last revision\n> \n> $ hg st --rev 0:2\n> M a\n> $ hg cat -r 0 a\n> a\n> $ hg cat -r 2 a\n> a\n\nThat is really scary. What use is \"hg stat --rev\" then? Not blaming you\nfor hg, of course.\n\nOn that tangent, I just noticed recently that hg has no python api.\nSeriously [1]. They even tell us not to use the internal python api.\nmsysgit has been lacking support for newer hg, and you've had to add\nsupport for older versions (hg 1.9 will be around on quite some\nstable/LTS/EL distro releases) after developing on newer/current ones.\nI'm wondering how well that scales in the long term (telling from\ngit-svn experience: it does not scale well), or whether using some\nstable api like 'hgapi' would be a huge bottleneck.\n\nCheers,\nMichael\n\n[1] http://mercurial.selenic.com/wiki/MercurialApi\n\nReally funny to see they recommend the command line as api ;)\n"},{"id":"202547","messageId":"CAMP44s3i1M9YtQb-EG+LS8DbwX10q2xE-LdxZCy3Xa_x3tQ9kA@mail.gmail.com","threadId":"31960","inReplyTo":"5097860E.5040607@drmicha.warpmail.net","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-05T15:22:48Z","receivedAt":"2012-11-05T15:22:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:\n>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber\n>> wrote:\n>>> Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:\n>>>> On 11/01/2012 02:46 PM, René Scharfe wrote:\n>>>>>\n>>>>> Also, and I'm sure you didn't know that, \"Jedem das Seine\" (to each\n>>>>> his own) was the slogan of the Buchenwald concentration camp. For\n>>>>> that reason some (including me) hear the unspoken cynical\n>>>>> half-sentence \"and some people just have to be sent to the gas\n>>>>> chamber\" when someone uses this proverb.\n>>>>>\n>>>>\n>>>> It goes further back than that.\n>>>>\n>>>> \"Suum cuique pulchrum est\" (\"To each his own is a beautiful thing\") is\n>>>> a latin phrase said to be used frequently in the roman senate when\n>>>> senators politely agreed to disagree and let a vote decide the outcome\n>>>> rather than debating further.\n>>>>\n>>>> Please don't let the twisted views of whatever nazi idiot thought it\n>>>> meant \"you may have the wrong faith and therefore deserve to die, so you\n>>>> shall\" pollute it. The original meaning is both poetic and democratic,\n>>>> and I firmly believe most people have the original meaning to the fore\n>>>> of their mind when using it. After all, very few people knowingly quote\n>>>> nazi concentration camp slogans.\n>>>>\n>>>\n>>> In fact, many German terms and words are \"forbidden area\" since Nazi\n>>> times, but I don't think this one carries the same connotation.\n>>>\n>>> But that is a side track.\n>>>\n>>> Collaboration (and code review is a form of collaboration) requires\n>>> communication. The linked code of conduct pages describe quite well how\n>>> to ensure a productive environment in which \"everyone\" feels comfortable\n>>> communicating and collaborating.\n>>\n>> Yes, but that's assuming we want \"everyone\" to feel comfortable\n>> communicating and collaborating.\n>\n> I put \"everyone\" in quotes because you can never reach 100%, so\n> \"everyone\" means almost everyone.\n>\n> Undeniably, the answers in this and the other threads show that on the\n> git mailing list, \"everyone\" wants \"everyone\" to feel comfortable\n> communicating and collaborating.\n\nAnd that might be a mistake. Because \"everyone\" doesn't include the\npeople that are able to put personal differences aside, and\nconcentrate on technical merits.\n\n>> I cite again the example of the Linux\n>> kernel, where certainly not \"everyone\" feels that way. But somehow\n>\n> It's a different list with different standards and tone, so it doesn't\n> really matter for our list. That being said:\n\nIf you don't want to take into consideration what the most successful\nsoftware project in history does... up to you.\n\n>> they manage to be perhaps the most successful software project in\n>> history. And I would argue even more: it's _because_ not everyone\n>> feels comfortable, it's because ideas and code are criticized freely,\n>> and because only the ones that do have merit stand. If you are able to\n>> take criticism, and you are not emotionally and personally attacked to\n>> your code and your ideas, you would thrive in this environment. If you\n>> don't want your precious little baby code to fight against the big\n>> guys, then you shouldn't send it out to the world.\n>\n> For one thing, contributors on the kernel list are open to technical\n> arguments, and that includes the arguments of others; just like we are\n> here. On the other hand, you seem to rebuke \"any\" (most) technical\n> argument in harsh words as if it were a personal attack; at least that's\n> how your answers come across to me (and apparently others). That really\n> makes it difficult for most of us here to argue with you technically,\n> which is a pity. That lack of openness for the arguments of others would\n> make your life difficult on the kernel list also.\n\nIt doesn't. And I don't.\n\nThere is no lack of openness from my part. I hear all technical\narguments, and I reply on a technical basis. The problem seems to be\nis that you expect the code submitted to be criticized, but not the\ncriticism it receives. IOW; the submitter has to put up with anything\nanybody says about his/her code and ideas, but the *reviewer* is\nuntouchable; the submitter cannot ever criticize the reviewer. I can\ntell you that doesn't happen in the Linux kernel; the review process\nis a _discussion_, not a one-way communication, and discussions can be\nheated up, but the end result is better code, *both* sides are open to\ncriticism, the submitter, *and* the reviewer.\n\nIt seems to me that you think in the git mailing list the submitter\nshould never put in question the criticism of the reviewer.\n\nIf that's not the case, show me a single instance when I rebuke\ntechnical arguments in *harsh* words... perhaps, you think any\nrebuking is \"harsh\". Specifically, show me an instance were *I* was\nharsh, and the reviewer was not.\n\nIf you cannot show instances of this, then your statement that I\nrebuke harshly doesn't stand; I rebuke, that's all.\n\n> A completely different issue is that of language. You talk German on a\n> German list and English on an international list. You talk \"kernel\n> English\" on the kernel list, which is full of words and phrases you\n> would never use in a normal social setting where you talk to people in\n> person; it would be completely unacceptable. Here on the Git list, we\n> prefer to talk like in a normal, albeit colloquial social setting. If\n> you're open for advice: just imagine talking to the people here in\n> person, to colleagues across your desk, and you have a good guideline.\n\nIf a submitter cannot rebuke, why would I want to contribute to such a\nproject? If we cannot speak openly why would I want to contribute?\n\nI wouldn't.\n\n> And no, using the same or similar language does not make us the same at\n> all. Using the same language is the natural prerequisite for successful\n> communication.\n\nNobody said otherwise.\n\n> Felipe, please try to see the efforts many of us are making here in\n> order to keep you as a contributor, and reward it by accepting the\n> advice to revise your language: colleague to colleague.\n\nThanks, but no thanks. I contribute on my free time, and if\ncontributing is not a fun process, why would I?\n\nIt seems to me that you feel you are not only entitled to my code, but\nto never criticize back. I've seen this happen multiple times now,\nwhen I send patches, which are a *contribution*, and the reviewers\nexpect me to address every and all issues they raise without\ncriticizing back, or that somehow it's my *responsibility* to address\ntheir concerns, even if I don't agree. I'm sorry but it's not.\n\nIn a truly technical project code speaks, and if you as a reviewer\nfeel something has to be changed, and the submitter (which is acting\non his/her own volition and free time) is not willing to do it, he/her\nhimself/herself can take the code and do whatever modifications to it,\nor the commit message, seem necessary. *Not* to keep bashing the\nsubmitter until they do it exactly as they want as if somehow it was\ntheir *responsibility*.\n\nThe spirit of open source is *collaboration*, and what you seem to\nexpect here is that I do everything. Not only do I have to come up\nwith the code, I have to come up with a full book chapter of commit\nmessage explaining all the history and introducing how the code works\nto people unfamiliar with it, and I have to hear review criticism\nwithout arguing back, and I have to implement it even if I disagree,\nand I have to be careful about what every word I say might be taken by\npeople from other cultures (but they don't), and I can never say\nanything that might under certain circumstances and assumptions be\nconsidered offensive (even though they can). And never criticize back\nthe hidden guidelines.\n\nThis is not collaborative, this only ensures that you will get a very\nspecific kind of contributors.\n\nIf what you want is a closely-knitted circle of friends that are\nlike-minded, then this seems like the right approach.\n\nIf what you want is to have a good project, with good code, it might not.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202548","messageId":"CAMP44s1AELcssUZsa+2kCdbA7DLDDNFtWzGbOvMUP5AKnHByow@mail.gmail.com","threadId":"31960","inReplyTo":"5097C970.9010901@drmicha.warpmail.net","subject":"Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-05T15:36:56Z","receivedAt":"2012-11-05T15:36:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 5, 2012 at 3:13 PM, Michael J Gruber\n wrote:\n> Felipe Contreras venit, vidit, dixit 02.11.2012 19:01:\n\n>> I talked with some people in #mercurial, and apparently there is a\n>> concept of a 'changelog' that is supposed to store these changes, but\n>> since the format has changed, the content of it is unreliable. That's\n>> not a big problem because it's used mostly for reporting purposes\n>> (log, query), not for doing anything reliable.\n>\n> Is the changelog stored in the repo (i.e. generated by the hg version at\n> commit time) or generated on the fly (i.e. generated by the hg version\n> at hand)? See also below.\n\nI don't know. I would expect it to be the former, and then when the\nformat changes, generated by the tool that did the conversion.\n\n>> To reliably see the changes, one has to compare the 'manifest' of the\n>> revisions involved, which contain *all* the files in them.\n>\n> 'manifest' == '(exploded) tree', right? Just making sure my hg fu is not\n> subzero.\n\nYeah, the tree. As I said, it contains all the files.\n\n>> That's what I was doing already, but I found a more efficient way to\n>> do it. msysGit is using the changelog, which is quite fast, but not\n>> reliable.\n>>\n>> Unfortunately while going trough mercurial's code, I found an issue,\n>> and it turns out that 1) is not correct.\n>>\n>> In mercurial, a file hash contains also the parent file nodes, which\n>> means that even if two files have the same content, they would not\n>> have the same hash, so there's no point in keeping track of them to\n>> avoid extracting the data unnecessarily, because in order to make sure\n>> they are different, you need to extract the data anyway, defeating the\n>> purpose.\n>\n> Do I understand correctly that neither the msysgit version nor yours can\n> detect duplicate blobs (without requesting them) because of that sha1 issue?\n\nThat's correct.\n\n> I'm really wondering why a file blob hash carries its history along in\n> the sha1. This appears completely strange to gitters (being brain washed\n> about \"content tracking\"), but may be due to hg's extensive use of\n> delta, or really: delta chains (which do have their merit on the server\n> side).\n\nIt is a surprise to me too. I see absolutely no reason why that would be useful.\n\nIt seems like bazaar does store the file hashes without the parent\ninfo, like git.\n\n>> Which means mercurial doesn't really behave as one would expect:\n>>\n>> # add files with the same content\n>>\n>> $ echo a > a\n>> $ hg ci -Am adda\n>> adding a\n>> $ echo a >> a\n>> $ hg ci -m changea\n>> $ echo a > a\n>> $ hg st --rev 0\n>> $ hg ci -m reverta\n>> $ hg log -G --template '{rev} {desc}\\n'\n>> @ 2 reverta\n>> |\n>> o 1 changea\n>> |\n>> o 0 adda\n>>\n>> # check the difference between the first and the last revision\n>>\n>> $ hg st --rev 0:2\n>> M a\n>> $ hg cat -r 0 a\n>> a\n>> $ hg cat -r 2 a\n>> a\n>\n> That is really scary. What use is \"hg stat --rev\" then? Not blaming you\n> for hg, of course.\n>\n> On that tangent, I just noticed recently that hg has no python api.\n> Seriously [1]. They even tell us not to use the internal python api.\n> msysgit has been lacking support for newer hg, and you've had to add\n> support for older versions (hg 1.9 will be around on quite some\n> stable/LTS/EL distro releases) after developing on newer/current ones.\n> I'm wondering how well that scales in the long term (telling from\n> git-svn experience: it does not scale well), or whether using some\n> stable api like 'hgapi' would be a huge bottleneck.\n\nI don't know. I have never really used mercurial until recently. I\ndon't know how often they change their APIs and/or repository formats.\nI would say the burden of updating to newer APIs is probably much less\nthan the burden of implementing code that accesses their repositories\ndirectly, and eventually possibly rewriting the code when they change\nthe format.\n\nIf we were to access the repository directly, I would choose to use\nRuby for that, but given that 'we' is increasingly looking like 'I'. I\nprobably wouldn't.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202555","messageId":"CAMP44s02upREXeV4e1LKLzJs+NNwtasitzJu1=FoTafj0OwBmQ@mail.gmail.com","threadId":"31960","inReplyTo":"CAMP44s3i1M9YtQb-EG+LS8DbwX10q2xE-LdxZCy3Xa_x3tQ9kA@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-05T15:58:33Z","receivedAt":"2012-11-05T15:58:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 5, 2012 at 4:22 PM, Felipe Contreras\n wrote:\n> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber\n> wrote:\n\n>> For one thing, contributors on the kernel list are open to technical\n>> arguments, and that includes the arguments of others; just like we are\n>> here. On the other hand, you seem to rebuke \"any\" (most) technical\n>> argument in harsh words as if it were a personal attack; at least that's\n>> how your answers come across to me (and apparently others). That really\n>> makes it difficult for most of us here to argue with you technically,\n>> which is a pity. That lack of openness for the arguments of others would\n>> make your life difficult on the kernel list also.\n\n...\n\n> If that's not the case, show me a single instance when I rebuke\n> technical arguments in *harsh* words... perhaps, you think any\n> rebuking is \"harsh\". Specifically, show me an instance were *I* was\n> harsh, and the reviewer was not.\n>\n> If you cannot show instances of this, then your statement that I\n> rebuke harshly doesn't stand; I rebuke, that's all.\n\nIn addition to this, I'm still waiting for an answer of what's wrong\nwith the words that started this thread:\n\nOn Wed, 31 Oct 2012, Felipe Contreras wrote:\n\n> It doesn't get any more obvious than that. But to each his own.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"202556","messageId":"5097E290.4030700@drmicha.warpmail.net","threadId":"31960","inReplyTo":"CAMP44s3i1M9YtQb-EG+LS8DbwX10q2xE-LdxZCy3Xa_x3tQ9kA@mail.gmail.com","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-05T16:00:16Z","receivedAt":"2012-11-05T16:00:16Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[trimmed down heavily by mjg]\nFelipe Contreras venit, vidit, dixit 05.11.2012 16:22:\n> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber\n> wrote:\n>> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:\n>>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber\n>>> wrote:\n\n> There is no lack of openness from my part. I hear all technical\n> arguments, and I reply on a technical basis. The problem seems to be\n> is that you expect the code submitted to be criticized, but not the\n> criticism it receives. IOW; the submitter has to put up with anything\n> anybody says about his/her code and ideas, but the *reviewer* is\n> untouchable; the submitter cannot ever criticize the reviewer. I can\n\nFeel free to criticize the criticism, just don't offend the criticizer\n(be it the reviewer or the submitter).\n\n> tell you that doesn't happen in the Linux kernel; the review process\n> is a _discussion_, not a one-way communication, and discussions can be\n> heated up, but the end result is better code, *both* sides are open to\n> criticism, the submitter, *and* the reviewer.\n\nExactly, both.\n\n>> And no, using the same or similar language does not make us the same at\n>> all. Using the same language is the natural prerequisite for successful\n>> communication.\n> \n> Nobody said otherwise.\n\nWell, you did in the post I responded to:\n\n>>> The dangers of \"everyone\" following the same style of communication,\n>>> and making \"everyone\" feel comfortable, is that \"everyone\" ends up\n>>> being the same kind of people\n\nIn any case, I feel I've showed enough efforts and there's no point in\ndragging this on.\n\nMichael\n"},{"id":"202557","messageId":"CAMP44s2CWb8FqDGG4-9X2soaQ+sBLkRRtrj0EkH1YSV8AUu9bg@mail.gmail.com","threadId":"31960","inReplyTo":"5097E290.4030700@drmicha.warpmail.net","subject":"Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-05T16:15:06Z","receivedAt":"2012-11-05T16:15:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 5, 2012 at 5:00 PM, Michael J Gruber\n wrote:\n> [trimmed down heavily by mjg]\n> Felipe Contreras venit, vidit, dixit 05.11.2012 16:22:\n>> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber\n>> wrote:\n>>> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:\n>>>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber\n>>>> wrote:\n>\n>> There is no lack of openness from my part. I hear all technical\n>> arguments, and I reply on a technical basis. The problem seems to be\n>> is that you expect the code submitted to be criticized, but not the\n>> criticism it receives. IOW; the submitter has to put up with anything\n>> anybody says about his/her code and ideas, but the *reviewer* is\n>> untouchable; the submitter cannot ever criticize the reviewer. I can\n>\n> Feel free to criticize the criticism, just don't offend the criticizer\n> (be it the reviewer or the submitter).\n\nAs I've said before; I've yet to see where exactly I have done so.\n\n>>> And no, using the same or similar language does not make us the same at\n>>> all. Using the same language is the natural prerequisite for successful\n>>> communication.\n>>\n>> Nobody said otherwise.\n>\n> Well, you did in the post I responded to:\n>\n>>>> The dangers of \"everyone\" following the same style of communication,\n>>>> and making \"everyone\" feel comfortable, is that \"everyone\" ends up\n>>>> being the same kind of people\n\nStyle of communication != language.\n\nYou can use the same language and have vastly different styles of communication.\n\nImagine a society where everyone has the same style of communication.\nWhere your free speech ends the moment you diverge from this style.\nWell, historically we know these societies have not worked, because\nthere's people with different styles of communication, and quite often\nit's these styles of communication that are needed for certain\nmessages important to society to be heard.\n\nSure, it doesn't make you all the same, but it certainly makes it a\nnarrow spectrum.\n\n> In any case, I feel I've showed enough efforts and there's no point in\n> dragging this on.\n\nHow convenient. When I ask you specifically for examples where I have\noffended anybody, or been harsh, you feel you have \"showed enough\nefforts\"?\n\nClaims require evidence.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}