{"thread":{"id":"33600","subject":"[PATCH 0/9] remote-helpers: fixes and cleanups","startedAt":"2013-04-25T11:20:40Z","lastAt":"2013-04-26T22:22:32Z","messageCount":49,"participants":["Felipe Contreras","Ramkumar Ramachandra","Stefano Lattarini","Thomas Rast","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":9},"messages":[{"id":"215428","messageId":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":null,"subject":"[PATCH 0/9] remote-helpers: fixes and cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:40Z","receivedAt":"2013-04-25T11:20:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nHere's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.\n\nOne of these might conflict with a series already in pu, if so, the code here\nshould be the prefered one.\n\nFelipe Contreras (9):\n remote-bzr: trivial cleanups\n remote-hg: remove extra check\n remote-bzr: fix bad state issue\n remote-bzr: add support to push URLs\n remote-hg: use hashlib instead of hg sha1 util\n remote-bzr: store converted URL\n remote-hg: use python urlparse\n remote-bzr: tell bazaar to be quiet\n remote-bzr: strip extra newline\n\n contrib/remote-helpers/git-remote-bzr | 47 ++++++++++++++++++++++++++++++-----\n contrib/remote-helpers/git-remote-hg | 17 ++++++-------\n 2 files changed, 48 insertions(+), 16 deletions(-)\n\n-- \n1.8.2.1\n"},{"id":"215429","messageId":"1366888849-19607-2-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:41Z","receivedAt":"2013-04-25T11:20:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 9 +++++----\n 1 file changed, 5 insertions(+), 4 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex aa7bc97..82bf7c7 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -94,7 +94,7 @@ class Marks:\n return self.last_mark\n \n def is_marked(self, rev):\n- return self.marks.has_key(rev)\n+ return rev in self.marks\n \n def new_mark(self, rev, mark):\n self.marks[rev] = mark\n@@ -224,7 +224,7 @@ def export_files(tree, files):\n else:\n mode = '100644'\n \n- # is the blog already exported?\n+ # is the blob already exported?\n if h in filenodes:\n mark = filenodes[h]\n final.append((mode, mark, path))\n@@ -521,7 +521,7 @@ def c_style_unescape(string):\n return string\n \n def parse_commit(parser):\n- global marks, blob_marks, bmarks, parsed_refs\n+ global marks, blob_marks, parsed_refs\n global mode\n \n parents = []\n@@ -555,7 +555,7 @@ def parse_commit(parser):\n mark = int(mark_ref[1:])\n f = { 'mode' : m, 'data' : blob_marks[mark] }\n elif parser.check('D'):\n- t, path = line.split(' ')\n+ t, path = line.split(' ', 1)\n f = { 'deleted' : True }\n else:\n die('Unknown file command: %s' % line)\n@@ -643,6 +643,7 @@ def do_export(parser):\n wt = repo.bzrdir.open_workingtree()\n wt.update()\n print \"ok %s\" % ref\n+\n print\n \n def do_capabilities(parser):\n-- \n1.8.2.1\n"},{"id":"215430","messageId":"1366888849-19607-3-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/9] remote-hg: remove extra check","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:42Z","receivedAt":"2013-04-25T11:20:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Not needed since we use xrange ourselves.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 4 ----\n 1 file changed, 4 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 5481331..0b7c81f 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -332,10 +332,6 @@ def export_ref(repo, name, kind, head):\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 = xrange(tip, head.rev() + 1)\n count = 0\n \n-- \n1.8.2.1\n"},{"id":"215431","messageId":"1366888849-19607-4-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/9] remote-bzr: fix bad state issue","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:43Z","receivedAt":"2013-04-25T11:20:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Carried from remote-hg.\n\nThe problem reportedly happened after doing a push that fails, the abort\ncauses the state of remote-hg to go bad, this happens because\nremote-hg's marks are not stored, but 'git fast-export' marks are.\n\nEnsure that the marks are _always_ stored.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex 82bf7c7..84734c7 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -32,6 +32,7 @@ import os\n import json\n import re\n import StringIO\n+import atexit\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]*)>$')\n@@ -728,6 +729,7 @@ def main(args):\n blob_marks = {}\n parsed_refs = {}\n files_cache = {}\n+ marks = None\n \n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'bzr', alias)\n@@ -754,6 +756,10 @@ def main(args):\n die('unhandled command: %s' % line)\n sys.stdout.flush()\n \n+def bye():\n+ if not marks:\n+ return\n marks.store()\n \n+atexit.register(bye)\n sys.exit(main(sys.argv))\n-- \n1.8.2.1\n"},{"id":"215432","messageId":"1366888849-19607-5-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 4/9] remote-bzr: add support to push URLs","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:44Z","receivedAt":"2013-04-25T11:20:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Just like in remote-hg.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 16 +++++++++++++---\n 1 file changed, 13 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex 84734c7..d6319d6 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -32,7 +32,7 @@ import os\n import json\n import re\n import StringIO\n-import atexit\n+import atexit, shutil, hashlib\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]*)>$')\n@@ -719,11 +719,11 @@ def main(args):\n global blob_marks\n global parsed_refs\n global files_cache\n+ global is_tmp\n \n alias = args[1]\n url = args[2]\n \n- prefix = 'refs/bzr/%s' % alias\n tags = {}\n filenodes = {}\n blob_marks = {}\n@@ -731,6 +731,13 @@ def main(args):\n files_cache = {}\n marks = None\n \n+ if alias[5:] == url:\n+ is_tmp = True\n+ alias = hashlib.sha1(alias).hexdigest()\n+ else:\n+ is_tmp = False\n+\n+ prefix = 'refs/bzr/%s' % alias\n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'bzr', alias)\n \n@@ -759,7 +766,10 @@ def main(args):\n def bye():\n if not marks:\n return\n- marks.store()\n+ if not is_tmp:\n+ marks.store()\n+ else:\n+ shutil.rmtree(dirname)\n \n atexit.register(bye)\n sys.exit(main(sys.argv))\n-- \n1.8.2.1\n"},{"id":"215433","messageId":"1366888849-19607-6-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 5/9] remote-hg: use hashlib instead of hg sha1 util","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:45Z","receivedAt":"2013-04-25T11:20:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"To be in sync with remote-bzr.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 0b7c81f..99abda4 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -22,6 +22,7 @@ import shutil\n import subprocess\n import urllib\n import atexit\n+import hashlib\n \n #\n # If you want to switch to hg-git compatibility mode:\n@@ -830,7 +831,7 @@ def main(args):\n \n if alias[4:] == url:\n is_tmp = True\n- alias = util.sha1(alias).hexdigest()\n+ alias = hashlib.sha1(alias).hexdigest()\n else:\n is_tmp = False\n \n-- \n1.8.2.1\n"},{"id":"215434","messageId":"1366888849-19607-7-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 6/9] remote-bzr: store converted URL","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:46Z","receivedAt":"2013-04-25T11:20:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Mercurial might convert the URL to something more appropriate, like an\nabsolute path. Lets store that instead of the original URL, which won't\nwork from a different working directory if it's relative.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 13 ++++++++++++-\n 1 file changed, 12 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex d6319d6..3d3b1c1 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -32,7 +32,7 @@ import os\n import json\n import re\n import StringIO\n-import atexit, shutil, hashlib\n+import atexit, shutil, hashlib, urlparse, subprocess\n \n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?<([^<>]*)>$')\n@@ -713,6 +713,14 @@ def get_repo(url, alias):\n \n return branch\n \n+def fix_path(alias, orig_url):\n+ url = urlparse.urlparse(orig_url, 'file')\n+ if url.scheme != 'file' or os.path.isabs(url.path):\n+ return\n+ abs_url = urlparse.urljoin(\"%s/\" % os.getcwd(), orig_url)\n+ cmd = ['git', 'config', 'remote.%s.url' % alias, \"bzr::%s\" % abs_url]\n+ subprocess.call(cmd)\n+\n def main(args):\n global marks, prefix, dirname\n global tags, filenodes\n@@ -741,6 +749,9 @@ def main(args):\n gitdir = os.environ['GIT_DIR']\n dirname = os.path.join(gitdir, 'bzr', alias)\n \n+ if not is_tmp:\n+ fix_path(alias, url)\n+\n if not os.path.exists(dirname):\n os.makedirs(dirname)\n \n-- \n1.8.2.1\n"},{"id":"215435","messageId":"1366888849-19607-8-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 7/9] remote-hg: use python urlparse","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:47Z","receivedAt":"2013-04-25T11:20:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It's simpler, and we don't need to depend on certain Mercurial versions.\n\nAlso, now we don't update the URL if 'file://' is not present.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-hg | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 99abda4..67c3074 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -12,7 +12,7 @@\n # For remote repositories a local clone is stored in\n # \"$GIT_DIR/hg/origin/clone/.hg/\".\n \n-from mercurial import hg, ui, bookmarks, context, util, encoding, node, error\n+from mercurial import hg, ui, bookmarks, context, encoding, node, error\n \n import re\n import sys\n@@ -22,7 +22,7 @@ import shutil\n import subprocess\n import urllib\n import atexit\n-import hashlib\n+import urlparse, hashlib\n \n #\n # If you want to switch to hg-git compatibility mode:\n@@ -788,11 +788,11 @@ def do_export(parser):\n print\n \n def fix_path(alias, repo, orig_url):\n- repo_url = util.url(repo.url())\n- url = util.url(orig_url)\n- if str(url) == str(repo_url):\n+ url = urlparse.urlparse(orig_url, 'file')\n+ if url.scheme != 'file' or os.path.isabs(url.path):\n return\n- cmd = ['git', 'config', 'remote.%s.url' % alias, \"hg::%s\" % repo_url]\n+ abs_url = urlparse.urljoin(\"%s/\" % os.getcwd(), orig_url)\n+ cmd = ['git', 'config', 'remote.%s.url' % alias, \"hg::%s\" % abs_url]\n subprocess.call(cmd)\n \n def main(args):\n-- \n1.8.2.1\n"},{"id":"215436","messageId":"1366888849-19607-9-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 8/9] remote-bzr: tell bazaar to be quiet","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:48Z","receivedAt":"2013-04-25T11:20:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Otherwise we get notification, progress bars, and what not.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex 3d3b1c1..19668a9 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -26,6 +26,7 @@ bzrlib.plugin.load_plugins()\n import bzrlib.generate_ids\n import bzrlib.transport\n import bzrlib.errors\n+import bzrlib.ui\n \n import sys\n import os\n@@ -755,6 +756,8 @@ def main(args):\n if not os.path.exists(dirname):\n os.makedirs(dirname)\n \n+ bzrlib.ui.ui_factory.be_quiet(True)\n+\n repo = get_repo(url, alias)\n \n marks_path = os.path.join(dirname, 'marks-int')\n-- \n1.8.2.1\n"},{"id":"215437","messageId":"1366888849-19607-10-git-send-email-felipe.contreras@gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 9/9] remote-bzr: strip extra newline","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T11:20:49Z","receivedAt":"2013-04-25T11:20:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It's added by fast-export, the user didn't type it.\n\nSigned-off-by: Felipe Contreras \n---\n contrib/remote-helpers/git-remote-bzr | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex 19668a9..8c316fe 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -549,6 +549,10 @@ def parse_commit(parser):\n parents.append(parser.get_mark())\n parser.next()\n \n+ # fast-export adds an extra newline\n+ if data[-1] == '\\n':\n+ data = data[:-1]\n+\n files = {}\n \n for line in parser:\n-- \n1.8.2.1\n"},{"id":"215465","messageId":"CALkWK0meg1FgU=-4MFoFGjpDq_oa9XR_+qeiseR0J85mS71dNg@mail.gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-2-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T18:19:42Z","receivedAt":"2013-04-25T18:19:42Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\n> index aa7bc97..82bf7c7 100755\n> --- a/contrib/remote-helpers/git-remote-bzr\n> +++ b/contrib/remote-helpers/git-remote-bzr\n> @@ -94,7 +94,7 @@ class Marks:\n> return self.last_mark\n>\n> def is_marked(self, rev):\n> - return self.marks.has_key(rev)\n> + return rev in self.marks\n\nWhy? Is the new form faster than the older one?\n\n> @@ -224,7 +224,7 @@ def export_files(tree, files):\n> else:\n> mode = '100644'\n>\n> - # is the blog already exported?\n> + # is the blob already exported?\n\nWhat is this? Whitespace?\n\n> @@ -521,7 +521,7 @@ def c_style_unescape(string):\n> return string\n>\n> def parse_commit(parser):\n> - global marks, blob_marks, bmarks, parsed_refs\n> + global marks, blob_marks, parsed_refs\n\nHow is this trivial? You just removed one argument.\n\n> @@ -555,7 +555,7 @@ def parse_commit(parser):\n> mark = int(mark_ref[1:])\n> f = { 'mode' : m, 'data' : blob_marks[mark] }\n> elif parser.check('D'):\n> - t, path = line.split(' ')\n> + t, path = line.split(' ', 1)\n\nHow on earth is this trivial? It changes the entire meaning!\n\n> @@ -643,6 +643,7 @@ def do_export(parser):\n> wt = repo.bzrdir.open_workingtree()\n> wt.update()\n> print \"ok %s\" % ref\n> +\n\nWhitespace?\n\nI'm outraged by this. What kind of changes are you pushing to\nremote-hg? A \"trivial cleanups\" bundling miscellaneous changes, with\nno commit message? Why don't you just squash everything into one\n\"miscellaneous changes\" patch?\n"},{"id":"215466","messageId":"CALkWK0mrMkLBRSKk3GwjYvh+tCtXU=efeuaZC4nKGTZosVyHrQ@mail.gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-3-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 2/9] remote-hg: remove extra check","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T18:23:04Z","receivedAt":"2013-04-25T18:23:04Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\n> index 5481331..0b7c81f 100755\n> --- a/contrib/remote-helpers/git-remote-hg\n> +++ b/contrib/remote-helpers/git-remote-hg\n> @@ -332,10 +332,6 @@ def export_ref(repo, name, kind, head):\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 = xrange(tip, head.rev() + 1)\n\nI'm surprised these four lines were even there in a previous revision.\n Again, you changed the meaning: if xrange() returns an empty range,\nyou must return, by extension.\n"},{"id":"215468","messageId":"CALkWK0=Q2KZPioYD21pYLzruBnFh_cpFLh_rDj7QDa3bOaCO6g@mail.gmail.com","threadId":"33600","inReplyTo":"1366888849-19607-6-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 5/9] remote-hg: use hashlib instead of hg sha1 util","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-25T18:25:50Z","receivedAt":"2013-04-25T18:25:50Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> To be in sync with remote-bzr.\n\nHuh? Why do you have to be in sync with remote-bzr? Are you sharing\ncode between remote-hg and remote-bzr?\n\n> @@ -830,7 +831,7 @@ def main(args):\n>\n> if alias[4:] == url:\n> is_tmp = True\n> - alias = util.sha1(alias).hexdigest()\n> + alias = hashlib.sha1(alias).hexdigest()\n\nDid you eve bother justifying this change with a line in the commit\nmessage? How is the new form different from the old form?\n"},{"id":"215476","messageId":"CAMP44s2nRHRFY_BRO7+x=CVKgrob78xZCpiV4Hk9sjWB_Q=vng@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0meg1FgU=-4MFoFGjpDq_oa9XR_+qeiseR0J85mS71dNg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T19:20:14Z","receivedAt":"2013-04-25T19:20:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 1:19 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\n>> index aa7bc97..82bf7c7 100755\n>> --- a/contrib/remote-helpers/git-remote-bzr\n>> +++ b/contrib/remote-helpers/git-remote-bzr\n>> @@ -94,7 +94,7 @@ class Marks:\n>> return self.last_mark\n>>\n>> def is_marked(self, rev):\n>> - return self.marks.has_key(rev)\n>> + return rev in self.marks\n>\n> Why? Is the new form faster than the older one?\n\nhas_key is deprecated.\n\n>> @@ -224,7 +224,7 @@ def export_files(tree, files):\n>> else:\n>> mode = '100644'\n>>\n>> - # is the blog already exported?\n>> + # is the blob already exported?\n>\n> What is this? Whitespace?\n\ns/blog/blob/\n\n>> @@ -521,7 +521,7 @@ def c_style_unescape(string):\n>> return string\n>>\n>> def parse_commit(parser):\n>> - global marks, blob_marks, bmarks, parsed_refs\n>> + global marks, blob_marks, parsed_refs\n>\n> How is this trivial? You just removed one argument.\n\nIt's not an argument.\n\n>> @@ -555,7 +555,7 @@ def parse_commit(parser):\n>> mark = int(mark_ref[1:])\n>> f = { 'mode' : m, 'data' : blob_marks[mark] }\n>> elif parser.check('D'):\n>> - t, path = line.split(' ')\n>> + t, path = line.split(' ', 1)\n>\n> How on earth is this trivial? It changes the entire meaning!\n\nAnd nobody has noticed any problem.\n\n>> @@ -643,6 +643,7 @@ def do_export(parser):\n>> wt = repo.bzrdir.open_workingtree()\n>> wt.update()\n>> print \"ok %s\" % ref\n>> +\n>\n> Whitespace?\n\nAka. trivial.\n\n> I'm outraged by this. What kind of changes are you pushing to\n> remote-hg? A \"trivial cleanups\" bundling miscellaneous changes, with\n> no commit message?\n\nThere are no miscellaneous changes other than the *possible* fix for\ndeleted files. Which we don't know if it would actually fix anything,\nbut as far as we know if it's a bug, nobody has seen it, and if it\nisn't, it's very unlikely that anybody is relying on the current\nbehavior.\n\nPlus the change seems to be obviously correct, as it comes from\nremote-hg, where somebody appeared to have found a bug.\n\nThat being said, I do remember writing an explanation for this in the\ncommit message:\n\n--\ncommit ca8c02dc7ea6395b1c864296f2500b718892fab8\nReflog: HEAD@{143} (Felipe Contreras )\nReflog message: rebase -i (fixup): remote-bzr: trivial cleanups\nAuthor: Felipe Contreras \nDate: Tue Apr 23 18:29:49 2013 -0500\n\n remote-bzr: trivial cleanups\n\n Mostly from remote-hg. It's possible that there's a fix to delete files\n with spaces.\n\n Signed-off-by: Felipe Contreras \n---\n\nYeap, there it is. It was just squashed by mistake.\n\nBut I do not care that much really. The patch is good either way, if\nyou don't like it, you go ahead and fix it, because I won't. I have\n174 remote-helper related patches in my queue, and nobody benefits\nfrom rambling about a one liner that is obviously correct, not you,\nnot me, not the users, not the developers.\n\nJunio of course might disagree and drop this patch, but then he would\nneed to deal with the fallout of possible conflicts. Or he can do the\nsensible thing and pick the commit message above. I have real issues\nto deal with, and I think the less-than-perfect commit messages in a\n*contrib* script that is extremely recent is a small price to pay for\nhaving nice and workable bzr and mercurial remote-helpers as soon as\npossible; our users would thank us, and in fact, they already are.\n\nIn my hurry to reorganize all the commits of my fourteen remote-helper\nbranches, I squashed the commit message of a trivial fix into trivial\ncleanups. Big whooping deal.\n\n> Why don't you just squash everything into one\n> \"miscellaneous changes\" patch?\n\nHyperbole much?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215477","messageId":"CAMP44s3oNZiNTotaWqf3=FtDh+Jzc3i2-Ox5=E8pKLYqWY=X-A@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0mrMkLBRSKk3GwjYvh+tCtXU=efeuaZC4nKGTZosVyHrQ@mail.gmail.com","subject":"Re: [PATCH 2/9] remote-hg: remove extra check","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T19:22:02Z","receivedAt":"2013-04-25T19:22:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 1:23 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\n>> index 5481331..0b7c81f 100755\n>> --- a/contrib/remote-helpers/git-remote-hg\n>> +++ b/contrib/remote-helpers/git-remote-hg\n>> @@ -332,10 +332,6 @@ def export_ref(repo, name, kind, head):\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 = xrange(tip, head.rev() + 1)\n>\n> I'm surprised these four lines were even there in a previous revision.\n> Again, you changed the meaning: if xrange() returns an empty range,\n> you must return, by extension.\n\nI'm not going to go back in history, but we were not always using\nxrange, but the mercurial API helper, which was dead slow, and in the\nend did basically an xrange().\n\n-- \nFelipe Contreras\n"},{"id":"215479","messageId":"5179842D.6060500@gmail.com","threadId":"33600","inReplyTo":"CALkWK0meg1FgU=-4MFoFGjpDq_oa9XR_+qeiseR0J85mS71dNg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2013-04-25T19:29:49Z","receivedAt":"2013-04-25T19:29:49Z","isPatch":true,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 04/25/2013 08:19 PM, Ramkumar Ramachandra wrote:\n> Felipe Contreras wrote:\n>> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\n>> index aa7bc97..82bf7c7 100755\n>> --- a/contrib/remote-helpers/git-remote-bzr\n>> +++ b/contrib/remote-helpers/git-remote-bzr\n>> @@ -94,7 +94,7 @@ class Marks:\n>> return self.last_mark\n>>\n>> def is_marked(self, rev):\n>> - return self.marks.has_key(rev)\n>> + return rev in self.marks\n> \n> Why? Is the new form faster than the older one?\n>\nI think the has_key() method is \"deprecated\" in modern python,\nand the 'key in dict' usage is more idiomatic.\n\n>> @@ -224,7 +224,7 @@ def export_files(tree, files):\n>> else:\n>> mode = '100644'\n>>\n>> - # is the blog already exported?\n>> + # is the blob already exported?\n> \n> What is this? Whitespace?\n>\nTypofix: s/blog/blob/\n\n>> @@ -521,7 +521,7 @@ def c_style_unescape(string):\n>> return string\n>>\n>> def parse_commit(parser):\n>> - global marks, blob_marks, bmarks, parsed_refs\n>> + global marks, blob_marks, parsed_refs\n> \n> How is this trivial? You just removed one argument.\n>\nMaybe bmarks was no longer used there as a global variable\n(left-over from previous patches?), so there is no longer any\nneed to declare it global.\n\n>> @@ -555,7 +555,7 @@ def parse_commit(parser):\n>> mark = int(mark_ref[1:])\n>> f = { 'mode' : m, 'data' : blob_marks[mark] }\n>> elif parser.check('D'):\n>> - t, path = line.split(' ')\n>> + t, path = line.split(' ', 1)\n> \n> How on earth is this trivial? It changes the entire meaning!\n>\nIndeed, that should best go in a separate path with a proper\nexplanation in the commit message.\n\n>> @@ -643,6 +643,7 @@ def do_export(parser):\n>> wt = repo.bzrdir.open_workingtree()\n>> wt.update()\n>> print \"ok %s\" % ref\n>> +\n> \n> Whitespace?\n>\nIsn't that obvious?\n\n> I'm outraged by this. What kind of changes are you pushing to\n> remote-hg? A \"trivial cleanups\" bundling miscellaneous changes, with\n> no commit message? Why don't you just squash everything into one\n> \"miscellaneous changes\" patch?\n>\nI have no opinion on this, so I won't comment.\n\nRegard,\n Stefano\n"},{"id":"215480","messageId":"CAMP44s2et3sCgtdEbQzo3VTmAE=9-RCXQn2eQKtU6b2HPk0Vhw@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0=Q2KZPioYD21pYLzruBnFh_cpFLh_rDj7QDa3bOaCO6g@mail.gmail.com","subject":"Re: [PATCH 5/9] remote-hg: use hashlib instead of hg sha1 util","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T19:30:48Z","receivedAt":"2013-04-25T19:30:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 1:25 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> To be in sync with remote-bzr.\n>\n> Huh? Why do you have to be in sync with remote-bzr? Are you sharing\n> code between remote-hg and remote-bzr?\n\nWe don't have to.\n\n>> @@ -830,7 +831,7 @@ def main(args):\n>>\n>> if alias[4:] == url:\n>> is_tmp = True\n>> - alias = util.sha1(alias).hexdigest()\n>> + alias = hashlib.sha1(alias).hexdigest()\n>\n> Did you eve bother justifying this change with a line in the commit\n> message? How is the new form different from the old form?\n\nWhy would it be any difference? It's a hex version of the SHA-1\ndigest. It would be the same in every language and every tool.\n\nAnd a bit of context: historically the reason I started remote-bzr was\nto show that we didn't need the *huge* infrastructure that is sitting\ngit_remote_helpers, which is nothing compared to what was prepared to\nbe merged for msysgit's remote-hg. I wrote it as a proof-of-concept to\nshow we didn't need a framework, and if we do, it would only be clear\nafter having _two_ remote helpers, which we now do. It might make\nsense to refactor the common parts into a framework later on, so\nhaving them in sync as much as it's reasonably possible makes sense.\n\nBut if even if it wasn't, there's nothing wrong with this patch. Also,\nwho knows, maybe old versions of mercurial don't have util.sha1(), or\nmaybe newer ones will move it, who knows.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215481","messageId":"CAMP44s1hw_Rq2=N+emKWMzKyVxO5FVLM_H9WJ3x5awte-siw=A@mail.gmail.com","threadId":"33600","inReplyTo":"5179842D.6060500@gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T19:33:38Z","receivedAt":"2013-04-25T19:33:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 2:29 PM, Stefano Lattarini\n wrote:\n> On 04/25/2013 08:19 PM, Ramkumar Ramachandra wrote:\n\n>>> @@ -521,7 +521,7 @@ def c_style_unescape(string):\n>>> return string\n>>>\n>>> def parse_commit(parser):\n>>> - global marks, blob_marks, bmarks, parsed_refs\n>>> + global marks, blob_marks, parsed_refs\n>>\n>> How is this trivial? You just removed one argument.\n>>\n> Maybe bmarks was no longer used there as a global variable\n> (left-over from previous patches?), so there is no longer any\n> need to declare it global.\n\nEven more, it never was used, it was a mistake carried when copying\nthis method from remote-hg; we don't have bookmarks in bazaar. And\nbmarks wasn't even used in this method in remote-hg either =/\n\nBut it would be obvious that it was not used once one ran the tests\nand they passed, which they do.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215502","messageId":"87bo92l5el.fsf@hexa.v.cablecom.net","threadId":"33600","inReplyTo":"CAMP44s2nRHRFY_BRO7+x=CVKgrob78xZCpiV4Hk9sjWB_Q=vng@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-25T20:30:26Z","receivedAt":"2013-04-25T20:30:26Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Felipe Contreras writes:\n\n> But I do not care that much really. The patch is good either way, if\n> you don't like it, you go ahead and fix it, because I won't. I have\n> 174 remote-helper related patches in my queue, and nobody benefits\n> from rambling about a one liner that is obviously correct, not you,\n> not me, not the users, not the developers.\n\nYou don't stick to the rules of this project, which have been pointed\nout already:\n\n The body should provide a meaningful commit message, which:\n\n . explains the problem the change tries to solve, iow, what is wrong\n with the current code without the change.\n\n . justifies the way the change solves the problem, iow, why the\n result with the change is better.\n\n . alternate solutions considered but discarded, if any.\n\nYour project is moving too fast to put up with the established\nprocedures in this community.\n\nIn fact you are pretty much holding us hostage with a \"take it or keep\nit broken while causing more work\" attitude:\n\n> Junio of course might disagree and drop this patch, but then he would\n> need to deal with the fallout of possible conflicts.\n\nYou did not respond well to reviews and criticism. Even the\nconstructive fine-let's-do-the-work-for-him kind that Peff offered.\n\nAnd on top of that, remote helpers are written against an interface that\nwas designed to allow working with external programs.\n\nSo why is this in git.git?\n\nWhy should we take any more contrib additions from you?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"215504","messageId":"7vip3a2vq0.fsf@alter.siamese.dyndns.org","threadId":"33600","inReplyTo":"CAMP44s2nRHRFY_BRO7+x=CVKgrob78xZCpiV4Hk9sjWB_Q=vng@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T20:36:55Z","receivedAt":"2013-04-25T20:36:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> But I do not care that much really. The patch is good either way, if\n> you don't like it, you go ahead and fix it, because I won't. I have\n> 174 remote-helper related patches in my queue, and nobody benefits\n> from rambling about a one liner that is obviously correct, not you,\n> not me, not the users, not the developers.\n\nThree random points.\n\n * For this particular patch [1/9], especially because this would\n land close to the corresponding remote-hg fixes (e.g. \"has_key is\n deprecated\"), I think it is sufficient to say \"port fixes from\n corresponding remote-hg patches\" (you said it in 0/9 and didn't\n say it in 1/9, though) without going into individual details.\n Anybody who wonders what these changes were about will have a\n clue to check contemporary patches to remote-hg that way.\n\n * You may want to hold onto those 174 patches and polish their\n explanation up to save the list audiences' time by avoiding this\n kind of useless \"why no explanation\" exchanges.\n\n * If you do not want to keep a readable history, it would mean that\n nobody but you will fix problems discovered in the future in\n remote-hg, and there is no point carrying it in my tree for other\n Git developers to look at it. The users are better off getting\n them from your tree and that will make it clear for them whom to\n ask help/fix for when they hit a snag.\n\n> Junio of course might disagree and drop this patch, but then he would\n> need to deal with the fallout of possible conflicts.\n\nA much more sensible thing in such a case for me to do actually is\nto drop the whole thing. I do not want to do that unless necessary.\n\n> ... I think the less-than-perfect commit messages in a\n> *contrib* script that is extremely recent is a small price to pay for\n> having nice and workable bzr and mercurial remote-helpers as soon as\n> possible\n\nI do not share this view at all. The users survived without it long\nenough; they can wait for a well maintained version. On the other\nhand, shipping something that will not be maintainable is not the\nway to help end users. It is being irresponsive to them.\n\nHelping other developers understand your code is a way to ensure\nthat your code that would help users will be kept maintained. I do\nnot agree with Ram at all when he says that developers are more\nimportant than users, and I agree with you that the project exists\nfor users, and not for developers. But you need to help your fellow\ndevelopers anyway by spending effort to keep your history readable,\nin order to help them help the users.\n\nDo not take the \"users matter\" mantra to the extreme. You need other\ndevelopers to put users first.\n"},{"id":"215507","messageId":"CAMP44s1uS23OvsDY+_YOBGMgc9t=FBEV3YvM34M9sLMEF9hnTg@mail.gmail.com","threadId":"33600","inReplyTo":"87bo92l5el.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T20:52:19Z","receivedAt":"2013-04-25T20:52:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast wrote:\n> Felipe Contreras writes:\n>\n>> But I do not care that much really. The patch is good either way, if\n>> you don't like it, you go ahead and fix it, because I won't. I have\n>> 174 remote-helper related patches in my queue, and nobody benefits\n>> from rambling about a one liner that is obviously correct, not you,\n>> not me, not the users, not the developers.\n>\n> You don't stick to the rules of this project, which have been pointed\n> out already:\n\nThe rules of the contrib area are different from the ones of the rest\nof the project.\n\n> Your project is moving too fast to put up with the established\n> procedures in this community.\n\nThat's one of the reasons it's in the contrib area.\n\n> In fact you are pretty much holding us hostage with a \"take it or keep\n> it broken while causing more work\" attitude:\n\nI'm the maintainer of this code, so it's my call. If Junio has a\nproblem with that, I would gladly take my code somewhere else. I doubt\nthat's in the best interest of anyone.\n\nBut if the problem is this particular patch (reaally?), Junio could\njust drop this particular patch. Are you seriously suggesting that the\nwhole contrib/remote-helpers should be dropped because this patch\nintroduces a one-liner fix without mentioning it in the commit\nmessage? Really? I haven't seen anybody complain about *any* of the\nother patches where I \"held the project hostage\" and refused to fix\nthe commit message or change the patch.\n\nOther than this instance, show me where exactly did I do that.\n\n>> Junio of course might disagree and drop this patch, but then he would\n>> need to deal with the fallout of possible conflicts.\n>\n> You did not respond well to reviews and criticism. Even the\n> constructive fine-let's-do-the-work-for-him kind that Peff offered.\n\nDefine \"respond well\". If your idea to \"respond well\" is to say \"Yes\nsir!\" to every criticism, then no, I didn't. OTOH, if it's to reply\nand address the issues with objective reasoning and an open mind, I\ndid.\n\nI don't understand this notion that every review criticism is valid\nand correct. They are not, and it's OK to point that out.. really. If\nthey turn to be valid and correct, the reviewer can surely\ncounter-argue and substantiate his/her claims.\n\nAnd I don't recall Peff ever doing this \"constructive\nfine-let's-do-the-work-for-him\" on any contrib/remote-helpers stuff.\n\n> So why is this in git.git?\n>\n> Why should we take any more contrib additions from you?\n\nBecause it's good for the users.\n\nIf you are seriously suggesting to drop contrib/remote-helpers, I\nsuggest that 1) don't do it in the review thread of a trivial patch 2)\nstart a new thread where you point multiple instances where the\nmaintainer of the code (me) failed to respond correctly to criticism\n(of remote-helpers's code), 3) show how this affects negatively the\nproject, and 4) ask for new maintainers if the job of the current one\nis not deemed up-to-par, and only if no maintainer steps up, drop the\ncode.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215512","messageId":"CAMP44s1RdZ19y8v+_=gwBzq1Tg5v8+TWAYCAVR-ZzNwZ0_m_Ng@mail.gmail.com","threadId":"33600","inReplyTo":"7vip3a2vq0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T21:35:48Z","receivedAt":"2013-04-25T21:35:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 3:36 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> But I do not care that much really. The patch is good either way, if\n>> you don't like it, you go ahead and fix it, because I won't. I have\n>> 174 remote-helper related patches in my queue, and nobody benefits\n>> from rambling about a one liner that is obviously correct, not you,\n>> not me, not the users, not the developers.\n>\n> Three random points.\n>\n> * For this particular patch [1/9], especially because this would\n> land close to the corresponding remote-hg fixes (e.g. \"has_key is\n> deprecated\"), I think it is sufficient to say \"port fixes from\n> corresponding remote-hg patches\" (you said it in 0/9 and didn't\n> say it in 1/9, though) without going into individual details.\n> Anybody who wonders what these changes were about will have a\n> clue to check contemporary patches to remote-hg that way.\n\nI don't see the value of pointing that out in the particular commit,\nsince you are the only one that would do anything with that\ninformation, and it seems the message came across.\n\nIf there's any issues with that, just drop the patch, and if there's\nissues with the rest of the series, just drop them. I'll resend when\nthe stuff is merged to master.\n\n> * You may want to hold onto those 174 patches and polish their\n> explanation up to save the list audiences' time by avoiding this\n> kind of useless \"why no explanation\" exchanges.\n\nThat's exactly what I've been doing.\n\nYou are extrapolating from this particular patch, which I already\nadmitted I made a mistake, and it's not really important in any way.\n\n> * If you do not want to keep a readable history, it would mean that\n> nobody but you will fix problems discovered in the future in\n> remote-hg, and there is no point carrying it in my tree for other\n> Git developers to look at it. The users are better off getting\n> them from your tree and that will make it clear for them whom to\n> ask help/fix for when they hit a snag.\n\nThe history *is* readable. If anybody has any problems with the commit\nmessages, the place to mention such problems is IN THE PATCH REVIEW.\nNobody has done that, because either nobody has any problems, or they\nare not interested. Either way, there's nothing I can do about it.\n\n*This* patch is an exception, and I'm not willing to waste time on\nthis extremely trivial patch. Drop it.\n\n>> Junio of course might disagree and drop this patch, but then he would\n>> need to deal with the fallout of possible conflicts.\n>\n> A much more sensible thing in such a case for me to do actually is\n> to drop the whole thing. I do not want to do that unless necessary.\n\nYou want to drop the whole series because of a cleanup patch with a\nless-than-perfect commit message? Even though there quite likely won't\nbe any conflicts if you drop the single patch. Fine, drop the whole\nseries.\n\n>> ... I think the less-than-perfect commit messages in a\n>> *contrib* script that is extremely recent is a small price to pay for\n>> having nice and workable bzr and mercurial remote-helpers as soon as\n>> possible\n>\n> I do not share this view at all. The users survived without it long\n> enough; they can wait for a well maintained version. On the other\n> hand, shipping something that will not be maintainable is not the\n> way to help end users. It is being irresponsive to them.\n\nAre you saying that because *ONE PATCH*, introduces a fix without\nmentioning it in the commit message, *THE WHOLE* project becomes\nunmaintainable?\n\nIf not, then why are we discussing about something that is not happening?\n\n> Helping other developers understand your code is a way to ensure\n> that your code that would help users will be kept maintained. I do\n> not agree with Ram at all when he says that developers are more\n> important than users, and I agree with you that the project exists\n> for users, and not for developers. But you need to help your fellow\n> developers anyway by spending effort to keep your history readable,\n> in order to help them help the users.\n\nAnd I am. Because I made a mistake in this patch doesn't mean the same\nhappened in all the patches.\n\nI am helping my fellow developers by replying to the comments they\nmake when I send the patches for review. Unfortunately, the only\ndeveloper other than you that has made any comment at all, Ramkumar\nRamachandra, did so in a bellicose tone, but I replied to all his\ncomments either way, which where invalid. The only comment where he is\nright and I acknowledged making a small mistake, is trivial, does not\ncause any issues, and can be easily dropped.\n\n> Do not take the \"users matter\" mantra to the extreme. You need other\n> developers to put users first.\n\nNo, I don't. It would be nice, yes, but not necessary.\n\nNow, let's drop this pointless discussion and deal with the actual\nissue. What do you want to do?\n\n1) Drop this patch\n2) Drop the whole series\n3) I reroll without the change that was not described\n\nAnything else, I'm not interested in doing. There's tasks with actual\nvalue to do.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215513","messageId":"7vwqrq1eco.fsf@alter.siamese.dyndns.org","threadId":"33600","inReplyTo":"CAMP44s1uS23OvsDY+_YOBGMgc9t=FBEV3YvM34M9sLMEF9hnTg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T21:37:27Z","receivedAt":"2013-04-25T21:37:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast wrote:\n>> Felipe Contreras writes:\n>>\n>>> But I do not care that much really. The patch is good either way, if\n>>> you don't like it, you go ahead and fix it, because I won't. I have\n>>> 174 remote-helper related patches in my queue, and nobody benefits\n>>> from rambling about a one liner that is obviously correct, not you,\n>>> not me, not the users, not the developers.\n>>\n>> You don't stick to the rules of this project, which have been pointed\n>> out already:\n>\n> The rules of the contrib area are different from the ones of the rest\n> of the project.\n\nYes and no. \n\nA contrib/ material may not be held to the same high standard, but\nthat does not mean a contrib/ area maintainer has a blank check to\ndo anything there.\n\nIt would be pretty obvious to people observing what happens in the\narea after a while, if the quality standard the area maintainer\nenforces is too out of whack, and at that point the area maintainer\ndeserves to be ridiculed ;-)\n\n> And I don't recall Peff ever doing this \"constructive\n> fine-let's-do-the-work-for-him\" on any contrib/remote-helpers stuff.\n\nI do not think Thomas was talking specific about contrib/ material\nbut your interaction in general with other developers.\n\nCf. http://thread.gmane.org/gmane.comp.version-control.git/220427/focus=220891\n\nFWIW, I thought \"that person was me\" response from him was more than\nreasonable, and I still do.\n"},{"id":"215515","messageId":"CAMP44s296Fum_jKx51dhmmnz0jKkXG+P4XcE5xGen-euVUtYdg@mail.gmail.com","threadId":"33600","inReplyTo":"7vwqrq1eco.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T21:49:30Z","receivedAt":"2013-04-25T21:49:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 4:37 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> But I do not care that much really. The patch is good either way, if\n>>>> you don't like it, you go ahead and fix it, because I won't. I have\n>>>> 174 remote-helper related patches in my queue, and nobody benefits\n>>>> from rambling about a one liner that is obviously correct, not you,\n>>>> not me, not the users, not the developers.\n>>>\n>>> You don't stick to the rules of this project, which have been pointed\n>>> out already:\n>>\n>> The rules of the contrib area are different from the ones of the rest\n>> of the project.\n>\n> Yes and no.\n>\n> A contrib/ material may not be held to the same high standard, but\n> that does not mean a contrib/ area maintainer has a blank check to\n> do anything there.\n\nNor did I claim I had one.\n\n> It would be pretty obvious to people observing what happens in the\n> area after a while, if the quality standard the area maintainer\n> enforces is too out of whack, and at that point the area maintainer\n> deserves to be ridiculed ;-)\n\nOf course, but the claim the rules are different still stands.\n\n>> And I don't recall Peff ever doing this \"constructive\n>> fine-let's-do-the-work-for-him\" on any contrib/remote-helpers stuff.\n>\n> I do not think Thomas was talking specific about contrib/ material\n> but your interaction in general with other developers.\n>\n> Cf. http://thread.gmane.org/gmane.comp.version-control.git/220427/focus=220891\n\nYeah but how is that relevant in this context? We are talking about a\nparticular patch of remote-bzr. And he immediately used that claim as\nammunition to suggest the whole remote-helpers should be dropped. It\ndoes not follow.\n\nAny suggestion to drop remote-helpers should use facts and arguments\nregarding remote-helpers.\n\n-- \nFelipe Contreras\n"},{"id":"215517","messageId":"7vsj2e1d83.fsf@alter.siamese.dyndns.org","threadId":"33600","inReplyTo":"CAMP44s1RdZ19y8v+_=gwBzq1Tg5v8+TWAYCAVR-ZzNwZ0_m_Ng@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T22:01:48Z","receivedAt":"2013-04-25T22:01:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> Three random points.\n>>\n>> * For this particular patch [1/9], especially because this would\n>> land close to the corresponding remote-hg fixes (e.g. \"has_key is\n>> deprecated\"), I think it is sufficient to say \"port fixes from\n>> corresponding remote-hg patches\" (you said it in 0/9 and didn't\n>> say it in 1/9, though) without going into individual details.\n>> Anybody who wonders what these changes were about will have a\n>> clue to check contemporary patches to remote-hg that way.\n>\n> If there's any issues with that, just drop the patch,...\n> ...\n> 1) Drop this patch\n> 2) Drop the whole series\n> 3) I reroll without the change that was not described\n\nJust in case you missed it, the first in the three-random-points was\n\"I personally think 1/9 that does not say anything about the minute\nand irrelevant details Ram kibitzed about is fine\". So \"Drop this\npatch\" is not something on the table in the first place.\n\n * After seeing that this change is a copy from recent remote-hg\n changes, a revier who did a little homework would easily find a\n change around has_key in recent patches.\n\n * A reviewer who did a little homework would know by reading a bit\n beyond the patch context to see that nobody uses \"bmarks\".\n\n * A reviewer who wondered how the two lines are different can stop\n staring at the screen, take a walk and come back with refreshed\n eyes to spot the difference between blog and blob very easily.\n\nFor these reasons, I personally do not think it is unreasonable to\nthrow comments like the ones on \"has_key\", \"global bmarks\", and\n\"blog vs blob\" into \"too obvious, not even deserve to be responded\"\nbin.\n\nHaving said that, I am more worried about wasting everybody's time\n(and this includes your time) with the impedance mismatch between\nyou and the rest of us.\n\nOur standard for explaining the change (either in the log or in the\ncomment) is to err on the descriptive side to be helpful even to\npeople new to the codebase. We do not require or encourage to state\nthe obvious. The issue is the definition of \"obviousness\" varies\neven among the rest of us and even for a single person depending on\nhow familiar that person is with the area of the code in question.\nBut the divide between you (alone) and the rest of us seems to be\nfar more vast than differences among the people other than you.\n\nEspecially the criteria I used in the above example for \"bmarks\"\nneed to be used carefully. If a reviewer needs to follow a very\ndeep callchain to convince himself why a change does not break\nthings, it is no longer obvious and deserves to be explained.\n\nSo I dunno. If you are not willing to change your ways and try to\nbe more descriptive to help others to understand what you are doing,\nthere is nothing I can do to help you.\n"},{"id":"215519","messageId":"CAMP44s1CTzO6J+QTDw_tmbkf-jfVxBzpfqY08_6RXrMuPr+CFw@mail.gmail.com","threadId":"33600","inReplyTo":"7vsj2e1d83.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-25T22:58:10Z","receivedAt":"2013-04-25T22:58:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 5:01 PM, Junio C Hamano wrote:\n\n> Having said that, I am more worried about wasting everybody's time\n> (and this includes your time) with the impedance mismatch between\n> you and the rest of us.\n>\n> Our standard for explaining the change (either in the log or in the\n> comment) is to err on the descriptive side to be helpful even to\n> people new to the codebase. We do not require or encourage to state\n> the obvious. The issue is the definition of \"obviousness\" varies\n> even among the rest of us and even for a single person depending on\n> how familiar that person is with the area of the code in question.\n> But the divide between you (alone) and the rest of us seems to be\n> far more vast than differences among the people other than you.\n\nYou are missing my point, this is *ONE INSTANCE*. Show me another\ninstance where a reviewer complained about the lack of a descriptive\ncommit messages on *remote-helpers*.\n\n> Especially the criteria I used in the above example for \"bmarks\"\n> need to be used carefully. If a reviewer needs to follow a very\n> deep callchain to convince himself why a change does not break\n> things, it is no longer obvious and deserves to be explained.\n\nSo if I'm not willing to describe every little trivial cleanup change\nI do, what should I do then? Avoid those trivial changes?\n\nIf your true purpose of having descriptive commit messages is to\nimprove maintainability, then actually doing these cleanups should\nhave priority over a descriptive commit message, because doing the\ncleanups improves the maintainability even without a detailed\ndescription.\n\nClearly, your reasoning is incomplete.\n\n> So I dunno. If you are not willing to change your ways and try to\n> be more descriptive to help others to understand what you are doing,\n> there is nothing I can do to help you.\n\nI'm willing to change my ways when there's reason to change my ways,\nand so far, nobody has provided any evidence that my commit messages\nare indeed lacking, only *opinions*.\n\nOther people are perfectly fine with them:\nhttp://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras\n\nAnd the only reason we are wasting time, is that *you* make us waste\ntime. Any sensible reviewer would be context aware, notice that this\nis a contrib patch, and focus on behavioral changes, notice the\nmistake I made, and point that *one* of the changes was changing the\nbehavior, at which point I would agree and reroll either without that\nchange, or with the change in a separate commit (which I don't want to\ndo right now). The maintainer (you), wouldn't even have to reply at\nall.\n\nBut the reviewer failed to do so, and other contributors went even\nfurther, so the ball is in now in your court. IMO a sensible\nmaintainer would simply say \"Guys, stay on topic, what do we do with\nthis patch?\", but no, you allow people to suggest that not only the\nwhole series, but the whole sub-project be dropped, and to do so with\ntotally unrelated facts, and generalizing from *ONE INSTANCE* in the\nactual sub-project, and generally from ad hominem arguments.\n\nThis doesn't help anybody.\n\nShow me a systemic problem with the commit messages *in\nremote-helpers*, and then perhaps it would be worth to start *a new\nthread* to discuss them, but nobody has done so. We are still talking\nabout a *single patch*.\n\nAnd if you really really don't like the patch, say \"do X, or I drop\nthe patch\", or the series, and there would be no need for other\nreviewers to waste their time (if their comments were truly valid and\ncorrect, which they are not). There's no need to say anything more.\nAnd even if the reviewers were correct in their comments, allowing\nsuggestions such as that the whole sub-project should be dropped\nbecause of one patch is going to waste people's times, no matter what.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215521","messageId":"7vd2ti19zt.fsf@alter.siamese.dyndns.org","threadId":"33600","inReplyTo":"CAMP44s1CTzO6J+QTDw_tmbkf-jfVxBzpfqY08_6RXrMuPr+CFw@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:11:34Z","receivedAt":"2013-04-25T23:11:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> You are missing my point, this is *ONE INSTANCE*. Show me another\n> instance where a reviewer complained about the lack of a descriptive\n> commit messages on *remote-helpers*.\n\nYou are the one who is missing the point. My message was about your\npatches to _any_ part of our system, not limited to remote helpers.\n"},{"id":"215564","messageId":"CAMP44s2VnXV6YqgN4EqduzQS+UHFuu0XDsAzQQU5bKrEfOK0VA@mail.gmail.com","threadId":"33600","inReplyTo":"7vd2ti19zt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T01:19:29Z","receivedAt":"2013-04-26T01:19:29Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 25, 2013 at 6:11 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> You are missing my point, this is *ONE INSTANCE*. Show me another\n>> instance where a reviewer complained about the lack of a descriptive\n>> commit messages on *remote-helpers*.\n>\n> You are the one who is missing the point. My message was about your\n> patches to _any_ part of our system, not limited to remote helpers.\n\nI still see \"Re: [PATCH 1/9] remote-bzr: trivial cleanups\", if we are\ntalking about something else, let's do so and be clear in the subject,\nbut I don't see what this has to do with this trivial patch, the\nseries, or even remote-bzr in general (for which nobody has complained\nbout commit messages before).\n\n-- \nFelipe Contreras\n"},{"id":"215583","messageId":"CALkWK0mRfj1FGYymDrBqQ=d02mhPkevJKr5Ozhgurp8DMhiNjQ@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1RdZ19y8v+_=gwBzq1Tg5v8+TWAYCAVR-ZzNwZ0_m_Ng@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T09:32:33Z","receivedAt":"2013-04-26T09:32:33Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> I am helping my fellow developers by replying to the comments they\n> make when I send the patches for review. Unfortunately, the only\n> developer other than you that has made any comment at all, Ramkumar\n> Ramachandra, did so in a bellicose tone, but I replied to all his\n> comments either way, which where invalid.\n\nI've never wanted to pick fights with anyone, and I don't foresee\nhaving a desire to do so in the future. I was just saying what was on\nmy mind, which is along the lines of: you have written this patch with\nthe attitude \"I know what I'm doing, my users will benefit, and nobody\nelse is going to look at this patch anyway\"; I'm worried about what\nyour other patches look like if this is your attitude towards\ndevelopment. Junio is harping about the same thing: the impedance\nmismatch between you and the rest of us.\n\n> The history *is* readable. If anybody has any problems with the commit\n> messages, the place to mention such problems is IN THE PATCH REVIEW.\n> Nobody has done that, because either nobody has any problems, or they\n> are not interested. Either way, there's nothing I can do about it.\n\nThat's what I've been trying to say over and over again: _why_ are\npeople not reviewing your patches?\n\n0. Because nobody has any problems with them.\n\n1. Because nobody on the git list cares about remote-hg.\n\n2. Because you're stubborn as a mule, and the resulting thread often\nresults in long-winded discussions like this one (which wastes\neveryone's time). Therefore, the potential reviewer's reasoning is\nthat their review time is better spent elsewhere, where their review\nis actually appreciated.\n\nHint: it's not (0).\n\nIf you're claiming that (1) is the case, then why are you posting to\nthe git list and hitting everyone's inboxes? Maintain your project\noutside git.\n\nI'm claiming that it's (2). In which case, it's you who needs changing.\n\n> I'm willing to change my ways when there's reason to change my ways,\n> and so far, nobody has provided any evidence that my commit messages\n> are indeed lacking, only *opinions*.\n\nYou want a formal mathematical proof? We operate on opinions, and\nfreeze what we think we all agree with into \"community guidelines\".\n\n> Other people are perfectly fine with them:\n> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras\n\nSo you're now claiming that we're the ones at fault (Peff, Thomas,\nJunio, and me, among others). Okay, so why are you forcing your\nchanges and opinions down our throats? You're in the wrong community:\njoin a community of people who are more like you (or start your own\nproject), and stop wasting our time.\n\nJunio C Hamano wrote:\n> I do\n> not agree with Ram at all when he says that developers are more\n> important than users, and I agree with you that the project exists\n> for users, and not for developers.\n\nOn this.\n\nIf Peff were to suddenly stop working on git one day (because he was\nfrustrated with the community/ development practices), we'd all lose a\nlot more than if one random end-user switches to using hg for his tiny\npersonal projects. I'm _not_ claiming that there's a split between\nusers and users that are developers (we have one mailing list for\neveryone, and I like that). What I'm claiming is that we cannot (and\nshould not) pay equal attention to every user of git. Some users are\nmore important than others. Again, that does _not_ mean that we push\na change that benefits one important user but breaks everyone else's\nsetup.\n\nOfcourse the project exists for its users; we're not doing research.\nHowever, we don't all have to write tutorials to keep in touch with\nend-users who are completely detached from the development process\n(our time is better spent elsewhere), or even have an\nend-user-friendly bug tracker (where the SNR is very low). We don't\nhave to consciously reach out to people we're not connected to\ndirectly: if we're all sufficiently connected to the real world, the\nitches/ bugs worth working on will always find their way to us. We\nlive in a connected world.\n\nYes, I know. You're going to respond to this email arguing about why\nyou're Right and why I (and everyone else) is Wrong, either by quoting\nwhat Linus (TM) said and twisting it to mean what you want, belaboring\nover what you've already said, or something similar.\n\nI've given up on you, and I suspect a lot of other people have too.\n"},{"id":"215589","messageId":"CALkWK0ndinJPeufokYUiPeC_Hs=9WA71Xpd=K6vimJseXJsAOA@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1CTzO6J+QTDw_tmbkf-jfVxBzpfqY08_6RXrMuPr+CFw@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T12:19:09Z","receivedAt":"2013-04-26T12:19:09Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Any sensible reviewer would be context aware, notice that this\n> is a contrib patch, and focus on behavioral changes, notice the\n> mistake I made, and point that *one* of the changes was changing the\n> behavior, at which point I would agree and reroll either without that\n> change, or with the change in a separate commit (which I don't want to\n> do right now). The maintainer (you), wouldn't even have to reply at\n> all.\n\nPersonally, I think it is the job of the submitter to provide a really\nhelpful commit message and widen his review audience. If I'm hitting\nthe git mailing list with my patches, I try to make sure that nearly\neveryone on the list can understand what I've done and potentially\nreview it. Why else would I want to hit their inboxes with my\npatches?\n\nHere's my solution to the problem: maintain your project outside\ngit.git and merge changes in every couple of months or so with a\nsimple email containing a pull URL, addressing Junio. If Junio trusts\nyou enough to put the changes you send into contrib/ after a cursory\nglance, we're done. Start a separate mailing list for your project/\naccept GitHub pull requests via which contributors can send you\nchanges. No more fuss or drama on the git list about this. You can\nbe as stubborn as you want, and we go back to our lives. Everyone\nwins.\n\nIf you want to submit patches to other parts of git, you seriously\nneed to change your ways. Let's deal with that problem when it arises\nnext.\n"},{"id":"215608","messageId":"CAMP44s3WkfAuPjJ5Z91Hjx7Vp5P2C7n5Wh+7Rd49k9N_n+SxkA@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0mRfj1FGYymDrBqQ=d02mhPkevJKr5Ozhgurp8DMhiNjQ@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T18:34:10Z","receivedAt":"2013-04-26T18:34:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> I am helping my fellow developers by replying to the comments they\n>> make when I send the patches for review. Unfortunately, the only\n>> developer other than you that has made any comment at all, Ramkumar\n>> Ramachandra, did so in a bellicose tone, but I replied to all his\n>> comments either way, which where invalid.\n>\n> I've never wanted to pick fights with anyone, and I don't foresee\n> having a desire to do so in the future. I was just saying what was on\n> my mind, which is along the lines of: you have written this patch with\n> the attitude \"I know what I'm doing, my users will benefit, and nobody\n> else is going to look at this patch anyway\";\n\nThat is an assumption, it's wrong, and it's antagonistic. There's no\nneed for that.\n\n> I'm worried about what\n> your other patches look like if this is your attitude towards\n> development.\n\nMore assumptions and hypotheticals. Why don't we limit ourselves to\nfacts and reality?\n\n>> The history *is* readable. If anybody has any problems with the commit\n>> messages, the place to mention such problems is IN THE PATCH REVIEW.\n>> Nobody has done that, because either nobody has any problems, or they\n>> are not interested. Either way, there's nothing I can do about it.\n>\n> That's what I've been trying to say over and over again: _why_ are\n> people not reviewing your patches?\n>\n> 0. Because nobody has any problems with them.\n>\n> 1. Because nobody on the git list cares about remote-hg.\n>\n> 2. Because you're stubborn as a mule, and the resulting thread often\n> results in long-winded discussions like this one (which wastes\n> everyone's time). Therefore, the potential reviewer's reasoning is\n> that their review time is better spent elsewhere, where their review\n> is actually appreciated.\n>\n> Hint: it's not (0).\n>\n> If you're claiming that (1) is the case, then why are you posting to\n> the git list and hitting everyone's inboxes? Maintain your project\n> outside git.\n>\n> I'm claiming that it's (2). In which case, it's you who needs changing.\n\nThis is the false dichotomy fallacy, why does it have to be only one\nof these reasons? Couldn't it be a mixture of them? Maybe most people\ndon't care about remote-{bzr,hg}, maybe for the ones that do, most\ndon't see any problems in the patches, and maybe the ones that do see\nproblems in the patches don't bring them up, because of various\nreasons, like for example, they don't see them as major, and would\nrather fix them themselves later after investigation if they are\nindeed import problems, or maybe they just don't have time to engage\nin discussions.\n\nYes, there's a possibility that my stubbornness is a factor, and given\ntheir possible lack of time, and possible lack of interested, they\nchoose to not engage.\n\nBut to claim that *everyone* is in (2), and that there are no other\nfactors that made them land in (2) but my stubbornness is disingenuous\nat best.\n\nWhat would you think of a scientist that says, oh, \"I'm not going to\nreview that paper, because each time I do that, the reviewee defends\nit, and we end up with long-winded discussions\". This scientist\ndoesn't have the right spirit.\n\nIf you submit a review comment, you should be prepared to do defend\nit, just like you do when you submit a patch. And you should be\nprepared to accept that your patch has mistakes, just like you should\nbe prepared to accept that your review has mistakes. In this view,\nstubbornness is a good thing, because it brings the best in the\nreviewer, and in the reviewee, and in the end everyone benefits by\ntrying to achieve the higher quality possible. Just like stubbornness\nis a good thing in science, if both reviwer and reviewee fight for\ntheir point of view, only the best science wins, and we all benefit.\n\nThis is all of course if the stubbornness is warranted, but you\nhaven't claimed that it wasn't, simply that I was stubborn. Well, so\nwhat? Isn't that good?\n\nShow me where I was unreasonable, show me where I was wrong, not where\nI was stubborn. One can be stubborn and be right, in fact, when one is\nright, it's when one has all the more right to be stubborn.\n\nIf you are not prepared to defend your review, so are others, why to\nyou blame that on me? If you were right, you would be shown to be\nright. Period.\n\n>> I'm willing to change my ways when there's reason to change my ways,\n>> and so far, nobody has provided any evidence that my commit messages\n>> are indeed lacking, only *opinions*.\n>\n> You want a formal mathematical proof? We operate on opinions, and\n> freeze what we think we all agree with into \"community guidelines\".\n\nNo, we operate in evidence and reason, *not* opinion. Any reasonable\nperson would say \"well, I *think* this commit message needs more\ndescription, but I don't *know*, I don't have *evidence* for it, so\nI'm not going to fight to the death, as if I had\".\n\nAny reasonable person would know the difference between an opinion,\nand an objective fact. And react accordingly when another person\nattacks an opinion, which is not a big deal, and when an objective\nfact is attacked, which is a big deal.\n\n>> Other people are perfectly fine with them:\n>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras\n>\n> So you're now claiming that we're the ones at fault (Peff, Thomas,\n> Junio, and me, among others). Okay, so why are you forcing your\n> changes and opinions down our throats?\n\nWhere am I doing that?\n\nFirst of all, lets not act like bitching girlfriends arguing about who\ndidn't throw the trash three years ago. We are talking about\n*remote-bzr*, in fact, the subject is \"[PATCH 1/9] remote-bzr: trivial\ncleanups\". *NONE* of this discussion is relevant to that patch.\n\nIf we go one step above, to remote-helpers in general, nobody has\ncommented *ANYTHING* negative on those patches, you are the first to\ndo so. So how exactly did I managed to shove 71 patches down you\nthroat if everybody complained all the way?\n\nUltimately the decision to merge or not to merge comes to Junio, if\nyou don't like his decision, go complain to him, but I would be\nprepared with points in time where people complained about these\npatches, and there are no complains, so you have no ammunition at all\nwhatsoever.\n\nIf you are talking about something else, FFS, change the subject line.\nIf you want to argue about who didn't take out the trash three years\nago, fine, but lets do so clearly in another thread, not this one\nabout a *single trivial patch*.\n\n> You're in the wrong community:\n> join a community of people who are more like you (or start your own\n> project), and stop wasting our time.\n\nAnd this is how communities die. When everybody thinks the same, and\neveryone who thinks differently is displaced. A monoculture, a place\nfull of yes-men where nobody criticizes anybody, a circlejerk where\neveryone palms the back of everyone else. Eventually things go south,\nand nobody around you understands why.\n\nDiversity in a community is healthy. If you don't like people who\nthink differently, *you* have a problem. If you don't like standing up\nand defending your ideas, *you* have a problem. If you don't like\ndiscussing on the basis of evidence and reason, *you* have a problem.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215611","messageId":"CAMP44s1MHUc_jw5EQviSYWc9phWCYD-FK_gRA-0QYNcLix098w@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0ndinJPeufokYUiPeC_Hs=9WA71Xpd=K6vimJseXJsAOA@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T18:48:14Z","receivedAt":"2013-04-26T18:48:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 7:19 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> Any sensible reviewer would be context aware, notice that this\n>> is a contrib patch, and focus on behavioral changes, notice the\n>> mistake I made, and point that *one* of the changes was changing the\n>> behavior, at which point I would agree and reroll either without that\n>> change, or with the change in a separate commit (which I don't want to\n>> do right now). The maintainer (you), wouldn't even have to reply at\n>> all.\n>\n> Personally, I think it is the job of the submitter to provide a really\n> helpful commit message and widen his review audience. If I'm hitting\n> the git mailing list with my patches, I try to make sure that nearly\n> everyone on the list can understand what I've done and potentially\n> review it. Why else would I want to hit their inboxes with my\n> patches?\n\nIf you don't understand the reasoning and history behind remote-bzr,\nyou might be doing a disservice to everyone by commenting at all.\n\nBazaar is a dead project, and there are *real* users suffering as we\nspeak, bound to eternal SCM torment by evil dictators and political\nnon-speak. Even the worst of remote-bzr patches are a thousand times\nbetter than what you see in bzr code itself.\n\nTo give you some perspective, one commit broke a branch in the emacs\nproject, and ever since then people are not able to clone that branch.\nThis bug has been known for years, and nobody fixes it. Every time\nanybody tries to clone that branch, they need a special sequence of\ncommands.\n\nThey *need* something like remote-bzr to escape the horrendities of\nbzr, and all you are doing complaining about a sneaked fix is a\ndisservice to everyone. Yes, doing such a thing on git.c would not be\nparticularly great, but wouldn't be horrific either, fortunately we\nare not doing that!\n\nAnswer me, do you use bzr? No? Do you use remote-bzr? No? Then how in\nhell could you possibly have any contextual information to make even a\nguess as to what would be the impact of sneaking such a small fix? You\ncan't.\n\nBut why are we even speaking about this nonsense? This patch has been\ndropped. You want to review something, go review PATCH v2 1/9. Stop\narguing about stubbornness and hypotheticals, when there's actual code\nto review.\n\nWhat is your objective, do you want to help this project move forward or not?\n\n-- \nFelipe Contreras\n"},{"id":"215612","messageId":"CALkWK0mHCNdr7+QxmmB3jTnWTe8q0_ipXD0=1bKQdpLK07gnAg@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1MHUc_jw5EQviSYWc9phWCYD-FK_gRA-0QYNcLix098w@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T18:53:09Z","receivedAt":"2013-04-26T18:53:09Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> What is your objective, do you want to help this project move forward or not?\n\nForward, please.\n\nI want a solution to this persistent problem of conflict though. And\nI presented one in my previous email:\n\nHere's my solution to the problem: maintain your project outside\ngit.git and merge changes in every couple of months or so with a\nsimple email containing a pull URL, addressing Junio. If Junio trusts\nyou enough to put the changes you send into contrib/ after a cursory\nglance, we're done. Start a separate mailing list for your project/\naccept GitHub pull requests via which contributors can send you\nchanges. No more fuss or drama on the git list about this. You can\nbe as stubborn as you want, and we go back to our lives. Everyone\nwins.\n\nI'll probably even contribute small patches once in a while.\n"},{"id":"215617","messageId":"CAMP44s2SaKe7F-3H=b3ZBgDPDT+TrVPUBLrXg0XDY7n5ppdS0Q@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0mRfj1FGYymDrBqQ=d02mhPkevJKr5Ozhgurp8DMhiNjQ@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T19:19:21Z","receivedAt":"2013-04-26T19:19:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n\n> Junio C Hamano wrote:\n>> I do\n>> not agree with Ram at all when he says that developers are more\n>> important than users, and I agree with you that the project exists\n>> for users, and not for developers.\n>\n> On this.\n>\n> If Peff were to suddenly stop working on git one day (because he was\n> frustrated with the community/ development practices), we'd all lose a\n> lot more than if one random end-user switches to using hg for his tiny\n> personal projects.\n\nYeah but that's not happening is it? This is yet another hypothetical.\nLast I checked Peff never threatened to leave the project. Did I miss\na memo?\n\nThe last time somebody announced he was going to leave the project we\ndid what was reasonable; investigate the reasons. And that's what we\nwould do if Peff threatened to leave.\n\nBut fine, lets assume there's a hypothetical Peff, with hypothetical\nreasons to leave the project...\n\n> I'm _not_ claiming that there's a split between\n> users and users that are developers (we have one mailing list for\n> everyone, and I like that). What I'm claiming is that we cannot (and\n> should not) pay equal attention to every user of git. Some users are\n> more important than others. Again, that does _not_ mean that we push\n> a change that benefits one important user but breaks everyone else's\n> setup.\n\nThe importance of users changes all the time. The 15 year old kid in\nSao Paulo might not be important today, but he might be the single\nmost important contributor ten years from now. Hell, he might even\nreplace Junio as the maintainer.\n\nWho are you to decide which users are important, and which are not?\n\n> Ofcourse the project exists for its users; we're not doing research.\n> However, we don't all have to write tutorials to keep in touch with\n> end-users who are completely detached from the development process\n> (our time is better spent elsewhere),\n\nMaybe we should, and maybe we would see then some areas of\nimprovement. In fact, I have done so, and I do see lots of areas of\nimprovement in git's UI.\n\nI agree that there are more important areas, or rather, more fun to\nwork with, but the fact that most git developers don't pay too much\nattention to the pain of newcomers shows, and it's a very common\ncriticism of git; it's difficult to learn, it doesn't have a\nconsistent UI, many commands don't make sense. And I happen to agree\nwith that claim, but it's not an easy problem to solve, specially when\nyou care about *all* users, both old and new, which we do.\n\nWe should keep in mind the problems in git's UI for newcomers. There's\nno reason no to.\n\n> or even have an\n> end-user-friendly bug tracker (where the SNR is very low). We don't\n> have to consciously reach out to people we're not connected to\n> directly: if we're all sufficiently connected to the real world, the\n> itches/ bugs worth working on will always find their way to us. We\n> live in a connected world.\n\nNobody is claiming we need a bug tracker, there's no point in arguing\nabout that. The rate at which we fix bugs or our tracking of them is\nnot a problem.\n\n> Yes, I know. You're going to respond to this email arguing about why\n> you're Right and why I (and everyone else) is Wrong, either by quoting\n> what Linus (TM) said and twisting it to mean what you want, belaboring\n> over what you've already said, or something similar.\n\nWhere did I twist anything? You can see Linus talk himself:\nhttp://www.youtube.com/watch?v=kzKzUBLEzwk\n\nPoint me exactly where does he say some users are more important than\nothers, in fact, he is saying the opposite, the amount of people that\nneeded the Linux version compatibility flag was really really small,\nyet they did it, why? Because *all* users matter. Not that it matters\nwhat Linus says, what matters is that it's right; the moment you start\nbalkanizing your user base, the moment you start giving some them\nreason to fork the project. When was the last time Linux was forked?\nGNOME did exactly that, they said; you, users over there, we don't\ncare about you anymore, what did they do? Fork. They lost so many\nusers they had to revert their decision.\n\nShould we willingly and knowingly neglect some git user-base? No, why\nwould you want them to fork? In a way, git's UI has been so bad, that\nsome kind-of-forks have happened, that tells us something; the UI\nneeds some love, fortunately none of those forks worked, which tells\nus something too; it's not too atrocious.\n\nThat's not to say we shouldn't fix the UI, we should, in a way that\neveryone's happy, which is hard, but we will do it, eventually.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215620","messageId":"CALkWK0=J2_mAViDwu2MJNvLsUbVpoR68-sQR9fs=4of+E5wAjg@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s3WkfAuPjJ5Z91Hjx7Vp5P2C7n5Wh+7Rd49k9N_n+SxkA@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T19:30:29Z","receivedAt":"2013-04-26T19:30:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"[completely off-topic; don't worry, we're just having a friendly chat]\n\nFelipe Contreras wrote:\n> If you are not prepared to defend your review, so are others, why to\n> you blame that on me? If you were right, you would be shown to be\n> right. Period.\n\nFelipe, there are some things that are worth arguing about for a long\ntime (like the new revision spec I'm proposing in [1]), and others\nthat are not.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/222248/focus=222526\n\n> No, we operate in evidence and reason, *not* opinion. Any reasonable\n> person would say \"well, I *think* this commit message needs more\n> description, but I don't *know*, I don't have *evidence* for it, so\n> I'm not going to fight to the death, as if I had\".\n\nDon't you think you're taking reason to an extreme here? Reason is a\ntool that I use when I want. I don't want reason when I'm browsing\nGoogle Art Project or listening to Gentle Giant. Arguments like \"is\nthis commit message large enough?\" are really not worth the time and\neffort.\n\n> Ultimately the decision to merge or not to merge comes to Junio, if\n> you don't like his decision, go complain to him, but I would be\n> prepared with points in time where people complained about these\n> patches, and there are no complains, so you have no ammunition at all\n> whatsoever.\n\nI have no desire to \"attack\" you, Felipe. I respect you as a more\nexperienced developer than myself, and am trying to offer constructive\ncriticism.\n\nI don't have an ego (or consider myself important to the community).\nWhatever will happen will happen, with or without me.\n\n> And this is how communities die. When everybody thinks the same, and\n> everyone who thinks differently is displaced. A monoculture, a place\n> full of yes-men where nobody criticizes anybody, a circlejerk where\n> everyone palms the back of everyone else. Eventually things go south,\n> and nobody around you understands why.\n>\n> Diversity in a community is healthy. If you don't like people who\n> think differently, *you* have a problem. If you don't like standing up\n> and defending your ideas, *you* have a problem. If you don't like\n> discussing on the basis of evidence and reason, *you* have a problem.\n\nDiversity is certainly healthy, and I it would be nice to have you in\nthe community. We just have to find a way to keep the conflict down.\n"},{"id":"215622","messageId":"CAMP44s0r52L0_r-tQWCkLjOvV7jBghHLqMi6rh_UyChXvx6J1g@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0mHCNdr7+QxmmB3jTnWTe8q0_ipXD0=1bKQdpLK07gnAg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T19:39:32Z","receivedAt":"2013-04-26T19:39:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 1:53 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> What is your objective, do you want to help this project move forward or not?\n>\n> Forward, please.\n>\n> I want a solution to this persistent problem of conflict though. And\n> I presented one in my previous email:\n>\n> Here's my solution to the problem: maintain your project outside\n> git.git and merge changes in every couple of months or so with a\n> simple email containing a pull URL, addressing Junio. If Junio trusts\n> you enough to put the changes you send into contrib/ after a cursory\n> glance, we're done. Start a separate mailing list for your project/\n> accept GitHub pull requests via which contributors can send you\n> changes. No more fuss or drama on the git list about this. You can\n> be as stubborn as you want, and we go back to our lives. Everyone\n> wins.\n\nI already maintain my own clone outside of git.git[1], and I do\nalready accept pull requests[2], and people have sent me patches\ndirectly. The stuff I send to the git mailing list is what I think is\nready for merging. But there's only so much stuff I can catch.\n\nWe all benefit from these patches being reviewed in the git mailing\nlist, nobody has claimed otherwise. You are making the error of\nassuming that your review was actionable, that I should have done\nsomething, fix the commit message I suppose, but I don't think that's\nimportant.\n\nIn contrast, this is how a constructive, valid and helpful review looks like:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/220034\n\nJunio caught a problem I didn't see, I accepted the valid feedback,\nand I resent with a fix. We all benefit from such interactions, both\nusers, and developers. What's wrong with that?\n\nYou just got angry that your review didn't turn out to be helpful, is\nthat it? Why do you want to steal helpful review from the users of\nremote-{bzr,hg}? If that's not the case, please stop doing that. All\nreview is welcome, not all review should be acted upon.\n\nCheers.\n\n[1] https://github.com/felipec/git\n[2] https://github.com/felipec/git/pulls?direction=desc&page=1&sort=created&state=closed\n\n-- \nFelipe Contreras\n"},{"id":"215623","messageId":"CALkWK0mV-zZ1akdk7rt9HUic7E-gL17sH7dgepw8Bs7hmZ+=LA@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1MHUc_jw5EQviSYWc9phWCYD-FK_gRA-0QYNcLix098w@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T19:39:38Z","receivedAt":"2013-04-26T19:39:38Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> If you don't understand the reasoning and history behind remote-bzr,\n> you might be doing a disservice to everyone by commenting at all.\n\nFelipe, I'm trying to help. If you think my review lacked context,\nyou can write me a paragraph/ link me to an email and I will read it.\n\nIt's not reviewers and submitters \"attacking\" each other. It's\nhelping out other rational people in the community because you care\nfor their reviews. Don't practice exclusivity and label some people\nas \"not eligible to review\". That's not a good way to develop.\n\n> Bazaar is a dead project, and there are *real* users suffering as we\n> speak, bound to eternal SCM torment by evil dictators and political\n> non-speak. Even the worst of remote-bzr patches are a thousand times\n> better than what you see in bzr code itself.\n>\n> To give you some perspective, one commit broke a branch in the emacs\n> project, and ever since then people are not able to clone that branch.\n> This bug has been known for years, and nobody fixes it. Every time\n> anybody tries to clone that branch, they need a special sequence of\n> commands.\n>\n> They *need* something like remote-bzr to escape the horrendities of\n> bzr, and all you are doing complaining about a sneaked fix is a\n> disservice to everyone. Yes, doing such a thing on git.c would not be\n> particularly great, but wouldn't be horrific either, fortunately we\n> are not doing that!\n\nMy God. This is horror story.\n\n> Answer me, do you use bzr? No? Do you use remote-bzr? No? Then how in\n> hell could you possibly have any contextual information to make even a\n> guess as to what would be the impact of sneaking such a small fix? You\n> can't.\n\nNo Felipe, I don't use bzr.\n"},{"id":"215627","messageId":"CALkWK0nkt-uytJYpyZ94YCqV8L=m7v39TxKBaKfMJivh2COEng@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s0r52L0_r-tQWCkLjOvV7jBghHLqMi6rh_UyChXvx6J1g@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T19:56:57Z","receivedAt":"2013-04-26T19:56:57Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> We all benefit from these patches being reviewed in the git mailing\n> list, nobody has claimed otherwise. You are making the error of\n> assuming that your review was actionable, that I should have done\n> something, fix the commit message I suppose, but I don't think that's\n> important.\n\nWhat I'm saying is that you can get more eyes. A lot more eyes. If\nyou just write a proper commit message!\n\nWhy are you hitting everyone's inboxes with such cryptic patches that\nrequire either:\n1. The reviewer to trust what you've done and move on.\n2. The reviewer to do a lot of digging before the patch becomes\naccessible to her.\n\n> You just got angry that your review didn't turn out to be helpful, is\n> that it? Why do you want to steal helpful review from the users of\n> remote-{bzr,hg}? If that's not the case, please stop doing that. All\n> review is welcome, not all review should be acted upon.\n\nI'm not angry about anything, or trying to steal anything.\n\nWhat happened: New email. Felipe's remote-hg fixes. Okay, let's\nlook at this. Part 1. What?! [I wrote down what I was thinking as I\nwas reading the email]\n\nThis is where you _should_ apply reason: justify everything you've\ndone in the patch in your commit message. Why are you so stubborn\nabout not wanting to change your ways despite so many people telling\nyou? Is it your pride*?\n\n* Yes, I noticed that you have a huge ego. I consider it an undesirable trait.\n"},{"id":"215628","messageId":"CALkWK0m+5CCUC+62wdyFbPL5Be7GS1P35suYoZxk6yzuVmqBLQ@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0=J2_mAViDwu2MJNvLsUbVpoR68-sQR9fs=4of+E5wAjg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T19:59:10Z","receivedAt":"2013-04-26T19:59:10Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Diversity is certainly healthy, and I it would be nice to have you in\n> the community. We just have to find a way to keep the conflict down.\n\nAfter all, what are we asking for? Better commit messages. Why are\nyou making such a big deal out of it? You want diversity in \"length/\nform of commit messages\"?\n"},{"id":"215629","messageId":"CAMP44s1RTm3LRaL71U1LQ=RvA1qyOSQKsk1ptXeNP-GRk3rVrw@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0=J2_mAViDwu2MJNvLsUbVpoR68-sQR9fs=4of+E5wAjg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T20:00:11Z","receivedAt":"2013-04-26T20:00:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 2:30 PM, Ramkumar Ramachandra\n wrote:\n> [completely off-topic; don't worry, we're just having a friendly chat]\n>\n> Felipe Contreras wrote:\n>> If you are not prepared to defend your review, so are others, why to\n>> you blame that on me? If you were right, you would be shown to be\n>> right. Period.\n>\n> Felipe, there are some things that are worth arguing about for a long\n> time (like the new revision spec I'm proposing in [1]), and others\n> that are not.\n>\n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/222248/focus=222526\n\nI agree, and I have discussed about issues with diff in the past,\nunfortunately didn't reach any conclusion. I've tried to follow that\nthread, but I don't really know what is actually being proposed\nanymore.\n\nIf you are so keen in receiving feedback from your fellow developers,\nyou should eventually send an email summarizing the issues and the\nproposal for everyone to understand.\n\nIn contrast, I take it you agree this trivial patch is not worth\ndiscussing, which I agreed in my first reply.\n\n>> No, we operate in evidence and reason, *not* opinion. Any reasonable\n>> person would say \"well, I *think* this commit message needs more\n>> description, but I don't *know*, I don't have *evidence* for it, so\n>> I'm not going to fight to the death, as if I had\".\n>\n> Don't you think you're taking reason to an extreme here? Reason is a\n> tool that I use when I want. I don't want reason when I'm browsing\n> Google Art Project or listening to Gentle Giant. Arguments like \"is\n> this commit message large enough?\" are really not worth the time and\n> effort.\n\nReason is not a tool for appreciating art, reason is a tool for\ndiscovering truth, and if when arguing you are not interested in what\nis actually true, I'm not interested in arguing with you.\n\n>> Ultimately the decision to merge or not to merge comes to Junio, if\n>> you don't like his decision, go complain to him, but I would be\n>> prepared with points in time where people complained about these\n>> patches, and there are no complains, so you have no ammunition at all\n>> whatsoever.\n>\n> I have no desire to \"attack\" you, Felipe. I respect you as a more\n> experienced developer than myself, and am trying to offer constructive\n> criticism.\n>\n> I don't have an ego (or consider myself important to the community).\n> Whatever will happen will happen, with or without me.\n\nI appreciate your criticism, but that doesn't mean I must agree with\nit. And if I do agree, that doesn't mean I must act upon it.\n\n>> And this is how communities die. When everybody thinks the same, and\n>> everyone who thinks differently is displaced. A monoculture, a place\n>> full of yes-men where nobody criticizes anybody, a circlejerk where\n>> everyone palms the back of everyone else. Eventually things go south,\n>> and nobody around you understands why.\n>>\n>> Diversity in a community is healthy. If you don't like people who\n>> think differently, *you* have a problem. If you don't like standing up\n>> and defending your ideas, *you* have a problem. If you don't like\n>> discussing on the basis of evidence and reason, *you* have a problem.\n>\n> Diversity is certainly healthy, and I it would be nice to have you in\n> the community. We just have to find a way to keep the conflict down.\n\nA fine way to start is to not rattle away in trivial inconsequential patches.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215630","messageId":"CALkWK0=O0kp-d5pUNxMpAp4MzxORSod2H9wnMz37dLicm3mOZw@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1RTm3LRaL71U1LQ=RvA1qyOSQKsk1ptXeNP-GRk3rVrw@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T20:03:52Z","receivedAt":"2013-04-26T20:03:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> A fine way to start is to not rattle away in trivial inconsequential patches.\n\nI have something from Linus (TM) this time :)\n\nhttps://lkml.org/lkml/2004/12/20/255\n"},{"id":"215631","messageId":"CALkWK0n5ASBvS_swZ3fj11Utt0XKPgpk-V--=gYVaWVi=O2N2A@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s2SaKe7F-3H=b3ZBgDPDT+TrVPUBLrXg0XDY7n5ppdS0Q@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T20:17:27Z","receivedAt":"2013-04-26T20:17:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> The importance of users changes all the time. The 15 year old kid in\n> Sao Paulo might not be important today, but he might be the single\n> most important contributor ten years from now. Hell, he might even\n> replace Junio as the maintainer.\n\nYes, they do. Did I say that they don't change?\n\n> Where did I twist anything? You can see Linus talk himself:\n> http://www.youtube.com/watch?v=kzKzUBLEzwk\n\nYes, I watched the talk when you posted the link last time. And yes,\nI learnt something.\n\n> Should we willingly and knowingly neglect some git user-base? No, why\n> would you want them to fork? In a way, git's UI has been so bad, that\n> some kind-of-forks have happened, that tells us something; the UI\n> needs some love, fortunately none of those forks worked, which tells\n> us something too; it's not too atrocious.\n\nNo, we should never neglect. I believe in including everyone. In\nfact I take it to an extreme: on many instances, I have pointed out\nwhat I want specifically, and asked for a configuration option if it's\nnot necessarily a sane default. Git is a toolkit, and should be\nloaded with features that even a few users want.\n\n> That's not to say we shouldn't fix the UI, we should, in a way that\n> everyone's happy, which is hard, but we will do it, eventually.\n\nOn this, I think the way forward is complete-implicit'ness via\nconfiguration variables. I recently wrote remote.pushdefault to\nsimply 'git push', and proposed 'git push +ref1 ref2 ref3' to\nautomatically push to the correct pushdefaults (but that proposal was\nrejected).\n"},{"id":"215632","messageId":"CAMP44s0P4K8MSsuPLCSCVzNJnioCpTJ0puD-gduuDbmRcGZGOg@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0nkt-uytJYpyZ94YCqV8L=m7v39TxKBaKfMJivh2COEng@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T20:23:03Z","receivedAt":"2013-04-26T20:23:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 2:56 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> We all benefit from these patches being reviewed in the git mailing\n>> list, nobody has claimed otherwise. You are making the error of\n>> assuming that your review was actionable, that I should have done\n>> something, fix the commit message I suppose, but I don't think that's\n>> important.\n>\n> What I'm saying is that you can get more eyes. A lot more eyes. If\n> you just write a proper commit message!\n\nIt is a trivial obvious patch that changes very few lines of code, it\ndoesn't need more eyes in my opinion. For the patches that do need\neyes I do send descriptive commit messages. And some patches that I\ndon't think need eyes, but I think I could do wrong, I also write\ndescriptive messages.\n\nSo far, it looks like I was right in thinking this patch didn't need\nmore eyes. And I think my original commit description, which I deleted\nby mistake was more than enough \"Mostly from remote-hg. It's possible\nthat there's a fix to delete files with spaces\". Because so far,\nnobody has pointed out any actual issue, and it's not clear if this\npatch would benefit from even more eyes... probably won't.\n\n> Why are you hitting everyone's inboxes with such cryptic patches that\n> require either:\n> 1. The reviewer to trust what you've done and move on.\n> 2. The reviewer to do a lot of digging before the patch becomes\n> accessible to her.\n\nBecause there's no other way to get the changes into git.git. If you\nwan't I can add \"DO NOT REVIEW\" in the title, but I think \"trivial\ncleanups\" pretty much sums that what I feel, and actually I wouldn't\nwant people to _not_ review the patches, but rather to understand that\nI think they are trivial, and shouldn't worry too much about them.\n\n>> You just got angry that your review didn't turn out to be helpful, is\n>> that it? Why do you want to steal helpful review from the users of\n>> remote-{bzr,hg}? If that's not the case, please stop doing that. All\n>> review is welcome, not all review should be acted upon.\n>\n> I'm not angry about anything, or trying to steal anything.\n\nGood, so I'll keep sending the patches, because our users benefit from\nthe review.\n\n> What happened: New email. Felipe's remote-hg fixes. Okay, let's\n> look at this. Part 1. What?! [I wrote down what I was thinking as I\n> was reading the email]\n\nWrite what you see, not what you feel. Your questions about the code\nare fine, but making assumptions about what remote-bzr users must be\nsuffering by not having more descriptive commit messages are not. You\nalso assumed that I wanted to send that commit message, when that was\nnot true, I removed a chunk by mistake.\n\nIn general, you shouldn't make assumptions.\n\n> This is where you _should_ apply reason: justify everything you've\n> done in the patch in your commit message. Why are you so stubborn\n> about not wanting to change your ways despite so many people telling\n> you? Is it your pride*?\n\nStop asking these questions, I thought you already agreed this patch\nwas not worth discussing about. If you see *any other* patch that\ndoesn't have a good enough commit message, reply _there_. And if you\ndo want to pursue these questions irrespective of this patch, start a\nnew thread.\n\n> * Yes, I noticed that you have a huge ego. I consider it an undesirable trait.\n\nI don't think so, but even if I did, it doesn't matter, all that\nmatters is that my arguments are sound and valid, you should\nconcentrate on the ball, not on the man. The fact that I believe my\narguments are valid and sound doesn't make me egotistic, it might be\nthat they are actually valid and sound, and I'm simply assessing them\ncorrectly. I of course I'm willing to admit otherwise, based on\nevidence, and reason.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215633","messageId":"CALkWK0kTf_U3NMLTXS-spW-TbZ2x6-46EyEQtD6ZrZK2Tw-91w@mail.gmail.com","threadId":"33600","inReplyTo":"CAMP44s1RTm3LRaL71U1LQ=RvA1qyOSQKsk1ptXeNP-GRk3rVrw@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-26T20:28:08Z","receivedAt":"2013-04-26T20:28:08Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> If you are so keen in receiving feedback from your fellow developers,\n> you should eventually send an email summarizing the issues and the\n> proposal for everyone to understand.\n\nThanks. I'll do that in the morning.\n\n> Reason is not a tool for appreciating art, reason is a tool for\n> discovering truth, and if when arguing you are not interested in what\n> is actually true, I'm not interested in arguing with you.\n\nThere is no great truth to be discovered by arguing about the length\nof commit messages, Felipe. There are some \"guidelines\" or \"axioms\"\nupon which we build reason. If you want to argue till everything\nbreaks down to Peano's Axioms, do Foundations of mathematics or\nAnalytical philosophy. From personal experience, it's much more\nsatisfying than arguing with other humans (who aren't exact\ncreatures).\n\n> I appreciate your criticism, but that doesn't mean I must agree with\n> it. And if I do agree, that doesn't mean I must act upon it.\n\nWhy not? Am I being unreasonable in asking you to justify your\nchanges, so I can understand what you've done with one quick reading?\n"},{"id":"215634","messageId":"CAMP44s0YBQfq0RCJCSO8r8jjn1F7ZV+7W6K9qhOHVNmxQHmsFg@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0=O0kp-d5pUNxMpAp4MzxORSod2H9wnMz37dLicm3mOZw@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T20:28:50Z","receivedAt":"2013-04-26T20:28:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 3:03 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> A fine way to start is to not rattle away in trivial inconsequential patches.\n>\n> I have something from Linus (TM) this time :)\n>\n> https://lkml.org/lkml/2004/12/20/255\n\nI happen to agree with that, specially in the context of the Linux\nkernel, but I don't see how that applies here. Linus is talking about\ntrivial patches from an entry-level developer, who has much to learn,\nand this is one the best ways to do that.\n\nBut in particular, he is talking about the fact that prominent kernel\ndevelopers don't spend too much time on these trivial patches from\nthese entry-level developers, and that can be frustrating for these\nentry-level developers, which can be problematic.\n\nNothing at all related to what we are facing here.\n\n-- \nFelipe Contreras\n"},{"id":"215637","messageId":"CAMP44s1J1c7YfKZRwU6RwE8k1jFUvC_j77xQ-rzstvJimkxj_w@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0kTf_U3NMLTXS-spW-TbZ2x6-46EyEQtD6ZrZK2Tw-91w@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T20:46:15Z","receivedAt":"2013-04-26T20:46:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 3:28 PM, Ramkumar Ramachandra\n wrote:\n\n>> Reason is not a tool for appreciating art, reason is a tool for\n>> discovering truth, and if when arguing you are not interested in what\n>> is actually true, I'm not interested in arguing with you.\n>\n> There is no great truth to be discovered by arguing about the length\n> of commit messages, Felipe. There are some \"guidelines\" or \"axioms\"\n> upon which we build reason.\n\nAnd based on what do you build these guidelines and axioms if not\ntruth? Do you ask a computer to throw a number randomly from 0 to\ninfinite and that shall be the new axiom for what the perfect number\nof words a commit message should have?\n\nNo, you determine that based on experience, and convenience. You find\na number that convenient to write, not hundreds of pages, and a number\nthat would help the reader if the patch in case a bug in the changes\nis found on a later time, and that would help reviewers of code find\nissues, and understand it. But most importantly, the number depends on\nthe complexity of the code changes. Note that I'm not saying on size,\nbecause even one-liners can be extremely complex.\n\nIt's not arbitrary.\n\n> If you want to argue till everything\n> breaks down to Peano's Axioms, do Foundations of mathematics or\n> Analytical philosophy. From personal experience, it's much more\n> satisfying than arguing with other humans (who aren't exact\n> creatures).\n\nI do not want to argue the fundamentals of logic and reason, but\nunfortunately most people don't have a strong grasp on them.\n\nSo let me simply; truth matters, and how we find truth mattes. Which\nis why the degree of certainty we have on certain facts matters; you\nshouldn't act the same about a claim you are 10% sure it's true, than\nwith a claim you are 90% sure.\n\nIf you are 100% sure my commit messages are too short, then there's no\npoint in arguing with you. Nor if you think it doesn't matter if it's\n90%, or 50%, or even 0%. Because it's an opinion, and an opinion\ndoesn't need any facts, or certainty, it just needs a person to hold\nit, whatever unreasonable or unlikely it is.\n\n>> I appreciate your criticism, but that doesn't mean I must agree with\n>> it. And if I do agree, that doesn't mean I must act upon it.\n>\n> Why not? Am I being unreasonable in asking you to justify your\n> changes, so I can understand what you've done with one quick reading?\n\nI did justify everything, I just didn't act the way you wanted. I\ndidn't immediately resend the series with a full description of the\nchanges, because the changes, as I described before, are trivial. I\nsimply dropped the change you had a problem with, and moved on. It's\nperfectly reasonable.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215638","messageId":"CAMP44s3F2npFuXDS-wpAP+TqHiGBPJfFYK4LohTg_Z4Ta4yoeQ@mail.gmail.com","threadId":"33600","inReplyTo":"CALkWK0n5ASBvS_swZ3fj11Utt0XKPgpk-V--=gYVaWVi=O2N2A@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T21:00:32Z","receivedAt":"2013-04-26T21:00:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 3:17 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> The importance of users changes all the time. The 15 year old kid in\n>> Sao Paulo might not be important today, but he might be the single\n>> most important contributor ten years from now. Hell, he might even\n>> replace Junio as the maintainer.\n>\n> Yes, they do. Did I say that they don't change?\n\nBut you implied we shouldn't care about Thiago (our hypothetical\nfuture overlord), because he is among the users we should't care for\n(right now).\n\n>> Should we willingly and knowingly neglect some git user-base? No, why\n>> would you want them to fork? In a way, git's UI has been so bad, that\n>> some kind-of-forks have happened, that tells us something; the UI\n>> needs some love, fortunately none of those forks worked, which tells\n>> us something too; it's not too atrocious.\n>\n> No, we should never neglect. I believe in including everyone. In\n> fact I take it to an extreme: on many instances, I have pointed out\n> what I want specifically, and asked for a configuration option if it's\n> not necessarily a sane default. Git is a toolkit, and should be\n> loaded with features that even a few users want.\n>\n>> That's not to say we shouldn't fix the UI, we should, in a way that\n>> everyone's happy, which is hard, but we will do it, eventually.\n>\n> On this, I think the way forward is complete-implicit'ness via\n> configuration variables. I recently wrote remote.pushdefault to\n> simply 'git push', and proposed 'git push +ref1 ref2 ref3' to\n> automatically push to the correct pushdefaults (but that proposal was\n> rejected).\n\nIndeed, I learned about that, and I tried to use it, but I think\nthere's a lot that is missing, and I don't know myself what would be\nideal. I'm starting to think that a branch should have two upstreams;\none that is used for rebasing, and another that is used for pushing.\nBut I'm not sure.\n\nEventually, I would like to do 'git push' and I would push different\nbranches to different repositories in different destination branches\nin a way that requires multiple commands right now 'git push github\nfc/remote-old/hg:fc/remote/hg', 'git push --prune backup\nrefs/heads/*:refs/heads/* refs/tags/*:refs/tags/*'. And to figure\nthings out I'm also helping; I added the --prune option to push, and I\nadded color to visualize upstream branches in 'git branch'.\n\nBut I don't think any of those are as important as having a proper\n'git stage' command, and getting rid of --cached and --index, which\nwill be a huge effort, but would pay even bigger dividends. Step by\nstep.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215653","messageId":"7v1u9xvt88.fsf@alter.siamese.dyndns.org","threadId":"33600","inReplyTo":"CAMP44s0P4K8MSsuPLCSCVzNJnioCpTJ0puD-gduuDbmRcGZGOg@mail.gmail.com","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-26T22:10:15Z","receivedAt":"2013-04-26T22:10:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Good, so I'll keep sending the patches, because our users benefit from\n> the review.\n\nJust for the record, a patch sent to the list which nobody bothered\nto read does not really count as reviewed.\n\nYou can either\n\n (1) pace yourself when people are otherwise busy; or\n\n (2) send them anyway but not claim \"this was sent to the list two\n weeks ago, nobody complained, so it must be perfect\" when it is\n not picked up after a few weeks.\n\nOften (1) is a better strategy, as people who wanted to review but\notherwise were busy tend to declare patch bankruptcy after their\nbusy period ends.\n\nAlso, a reason that a patch goes uncommented is when it is difficult\nto judge. A patch with code change without sufficient explanation\nbehind the motivation to justify the change, a reviewer finds it\nmuch harder to convince himself that the patch is a good change, and\nit also is much harder to find which part of the change is wrong and\noffer improvements, compared to a patch with the same change that is\njustified properly.\n"},{"id":"215655","messageId":"CAMP44s1h50Xjo7H4Op=yDuO7pon2JdxZMBy2JSj2kf+Tnznd=w@mail.gmail.com","threadId":"33600","inReplyTo":"7v1u9xvt88.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/9] remote-bzr: trivial cleanups","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-26T22:22:32Z","receivedAt":"2013-04-26T22:22:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 26, 2013 at 5:10 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Good, so I'll keep sending the patches, because our users benefit from\n>> the review.\n>\n> Just for the record, a patch sent to the list which nobody bothered\n> to read does not really count as reviewed.\n\nNo, but I did my part, which is sending them for review.\n\n> You can either\n>\n> (1) pace yourself when people are otherwise busy; or\n\nI would, if there was a reason to.\n\n> (2) send them anyway but not claim \"this was sent to the list two\n> weeks ago, nobody complained, so it must be perfect\" when it is\n> not picked up after a few weeks.\n\nWhen have I ever done that?\n\n> Often (1) is a better strategy, as people who wanted to review but\n> otherwise were busy tend to declare patch bankruptcy after their\n> busy period ends.\n\nNot for remote-{bzr,hg}. I've yet to see anybody claim they would\nreview the patches thoroughly, if only they were given time. I've yet\nto see anybody claim they would review the patches thoroughly under\nany circumstance at all. And by that I mean the patches that really\nwould benefit from reviewing.\n\n> Also, a reason that a patch goes uncommented is when it is difficult\n> to judge. A patch with code change without sufficient explanation\n> behind the motivation to justify the change, a reviewer finds it\n> much harder to convince himself that the patch is a good change, and\n> it also is much harder to find which part of the change is wrong and\n> offer improvements, compared to a patch with the same change that is\n> justified properly.\n\nYes, but is that the case *HERE*? And no, single line changes that are\ntrivial and obvious don't count. Show me an important patch that\nsurely would benefit from reviewing that doesn't have sufficient\nexplanation. Show me an important patch that anybody is not convinced\nis a good patch. In the remote-{hg,bzr} context.\n\nIf there isn't any, I don't see why remote-{bzr,hg} should slow down.\n\nFor this patch, I don't care one iota.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}