{"thread":{"id":"32327","subject":"What's cooking in git.git (Dec 2012, #03; Wed, 12)","startedAt":"2012-12-12T23:58:15Z","lastAt":"2012-12-15T09:24:35Z","messageCount":16,"participants":["Junio C Hamano","Felipe Contreras","Max Horn","Michael Haggerty","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204811","messageId":"7vhanq257s.fsf@alter.siamese.dyndns.org","threadId":"32327","inReplyTo":null,"subject":"What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T23:58:15Z","receivedAt":"2012-12-12T23:58:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nA new maintenance release 1.8.0.2 was tagged with accumulated fixes\nwe have already been using on the 'master' front for a while.  The\ntip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are\ngetting into good shape in 'next', hopefully ready to be merged soon\nafter the 1.8.1 final.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* sp/shortlog-missing-lf (2012-12-11) 2 commits\n  (merged to 'next' on 2012-12-11 at 64b8429)\n + strbuf_add_wrapped*(): Remove unused return value\n + shortlog: fix wrapping lines of wraplen\n\n When a line to be wrapped has a solid run of non space characters\n whose length exactly is the wrap width, \"git shortlog -w\" failed to\n add a newline after such a line.\n\n Will cook in 'next'.\n\n\n* ap/log-mailmap (2012-12-11) 6 commits\n - [DO NOT MERGE] seems to break t4013 & t4014 among other things\n - log: Add --use-mailmap option\n - pretty: Use mailmap to display username and email\n - mailmap: Add mailmap structure to rev_info and pp\n - mailmap: Remove buffer length limit in map_user\n - Use split_ident_line to parse author and committer\n\n Clean up various codepaths around mailmap and teach the \"log\"\n machinery to use it.\n\n\n* jc/fetch-ignore-symref (2012-12-11) 1 commit\n - fetch: ignore wildcarded refspecs that update local symbolic refs\n\n Avoid false error from an attempt to update local symbolic ref via\n fetch.\n\n\n* md/gitweb-sort-by-age (2012-12-11) 1 commit\n - gitweb: Sort projects with undefined ages last\n\n Will merge to 'next'.\n\n\n* ss/nedmalloc-compilation (2012-12-11) 1 commit\n - nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2\n\n Will merge to 'next'.\n\n\n* wk/submodule-update-remote (2012-12-12) 3 commits\n - submodule add: If --branch is given, record it in .gitmodules\n - submodule update: add --remote for submodule's upstream changes\n - submodule: add get_submodule_config helper funtion\n\n Expecting a re-roll.\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ef/mingw-rmdir (2012-12-10) 1 commit\n + mingw_rmdir: do not prompt for retry when non-empty\n\n MinGW has a workaround when rmdir unnecessarily fails to retry with\n a prompt, but the logic was kicking in when the rmdir failed with\n ENOTEMPTY, i.e. was expected to fail and there is no point retrying.\n\n\n* ef/mingw-tty-getpass (2012-12-04) 6 commits\n  (merged to 'next' on 2012-12-07 at 1737ff1)\n + mingw: get rid of getpass implementation\n + mingw: reuse tty-version of git_terminal_prompt\n + compat/terminal: separate input and output handles\n + compat/terminal: factor out echo-disabling\n + mingw: make fgetc raise SIGINT if apropriate\n + mingw: correct exit-code for SIGALRM's SIG_DFL\n\n Update getpass() emulation for MinGW.\n\n\n* jc/prompt-command-doc (2012-12-11) 1 commit\n - git-prompt.sh: update PROMPT_COMMAND documentation\n\n Recently graduated git-prompt topic to use PROMPT_COMMAND was\n confusingly documented.  With a quick review, it may be a good\n idea to fast-track this to the 'master branch.\n\n--------------------------------------------------\n[Stalled]\n\n* fc/remote-bzr (2012-11-28) 10 commits\n - (fixup) test-bzr.sh: fix multi-line string assignment\n - remote-bzr: detect local repositories\n - remote-bzr: add support for older versions of bzr\n - remote-bzr: add support to push special modes\n - remote-bzr: add support for fecthing special modes\n - remote-bzr: add simple tests\n - remote-bzr: update working tree\n - remote-bzr: add support for remote repositories\n - remote-bzr: add support for pushing\n - Add new remote-bzr transport helper\n\n New remote helper for bzr (v3).  With minor fixes, this may be ready\n for 'next'.\n\n\n* mo/cvs-server-updates (2012-12-09) 18 commits\n - t9402: Use TABs for indentation\n - t9402: Rename check.cvsCount and check.list\n - t9402: Simplify git ls-tree\n - t9402: Add missing &&; Code style\n - t9402: No space after IO-redirection\n - t9402: Dont use test_must_fail cvs\n - t9402: improve check_end_tree() and check_end_full_tree()\n - t9402: sed -i is not portable\n - cvsserver Documentation: new cvs ... -r support\n - cvsserver: add t9402 to test branch and tag refs\n - cvsserver: support -r and sticky tags for most operations\n - cvsserver: Add version awareness to argsfromdir\n - cvsserver: generalize getmeta() to recognize commit refs\n - cvsserver: implement req_Sticky and related utilities\n - cvsserver: add misc commit lookup, file meta data, and file listing functions\n - cvsserver: define a tag name character escape mechanism\n - cvsserver: cleanup extra slashes in filename arguments\n - cvsserver: factor out git-log parsing logic\n\n Needs review by folks interested in cvsserver.\n\n\n* as/check-ignore (2012-11-08) 14 commits\n - t0007: fix tests on Windows\n - Documentation/check-ignore: we show the deciding match, not the first\n - Add git-check-ignore sub-command\n - dir.c: provide free_directory() for reclaiming dir_struct memory\n - pathspec.c: move reusable code from builtin/add.c\n - dir.c: refactor treat_gitlinks()\n - dir.c: keep track of where patterns came from\n - dir.c: refactor is_path_excluded()\n - dir.c: refactor is_excluded()\n - dir.c: refactor is_excluded_from_list()\n - dir.c: rename excluded() to is_excluded()\n - dir.c: rename excluded_from_list() to is_excluded_from_list()\n - dir.c: rename path_excluded() to is_path_excluded()\n - dir.c: rename cryptic 'which' variable to more consistent name\n\n Duy helped to reroll this.\n\n Expecting a re-roll.\n\n\n* aw/rebase-am-failure-detection (2012-10-11) 1 commit\n - rebase: Handle cases where format-patch fails\n\n I am unhappy a bit about the possible performance implications of\n having to store the output in a temporary file only for a rare case\n of format-patch aborting.\n\n\n* jk/lua-hackery (2012-10-07) 6 commits\n - pretty: fix up one-off format_commit_message calls\n - Minimum compilation fixup\n - Makefile: make \"lua\" a bit more configurable\n - add a \"lua\" pretty format\n - add basic lua infrastructure\n - pretty: make some commit-parsing helpers more public\n\n Interesting exercise. When we do this for real, we probably would want\n to wrap a commit to make it more like an \"object\" with methods like\n \"parents\", etc.\n\n\n* fc/remote-testgit-feature-done (2012-10-29) 1 commit\n - remote-testgit: properly check for errors\n\n Needs review and Ack (or Nack) from people involved in the remote\n helper interface for this to move forward.\n\n\n* rc/maint-complete-git-p4 (2012-09-24) 1 commit\n  (merged to 'next' on 2012-10-29 at af52cef)\n + Teach git-completion about git p4\n\n Comment from Pete will need to be addressed in a follow-up patch.\n\n\n* as/test-tweaks (2012-09-20) 7 commits\n - tests: paint unexpectedly fixed known breakages in bold red\n - tests: test the test framework more thoroughly\n - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up\n - tests: refactor mechanics of testing in a sub test-lib\n - tests: paint skipped tests in bold blue\n - tests: test number comes first in 'not ok $count - $message'\n - tests: paint known breakages in bold yellow\n\n Various minor tweaks to the test framework to paint its output\n lines in colors that match what they mean better.\n\n Has the \"is this really blue?\" issue Peff raised resolved???\n\n\n* jc/maint-name-rev (2012-09-17) 7 commits\n - describe --contains: use \"name-rev --algorithm=weight\"\n - name-rev --algorithm=weight: tests and documentation\n - name-rev --algorithm=weight: cache the computed weight in notes\n - name-rev --algorithm=weight: trivial optimization\n - name-rev: --algorithm option\n - name_rev: clarify the logic to assign a new tip-name to a commit\n - name-rev: lose unnecessary typedef\n\n \"git name-rev\" names the given revision based on a ref that can be\n reached in the smallest number of steps from the rev, but that is\n not useful when the caller wants to know which tag is the oldest one\n that contains the rev.  This teaches a new mode to the command that\n uses the oldest ref among those which contain the rev.\n\n I am not sure if this is worth it; for one thing, even with the help\n from notes-cache, it seems to make the \"describe --contains\" even\n slower. Also the command will be unusably slow for a user who does\n not have a write access (hence unable to create or update the\n notes-cache).\n\n Stalled mostly due to lack of responses.\n\n\n* jc/xprm-generation (2012-09-14) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n A toy to analyze how bad the clock skews are in histories of real\n world projects.\n\n Stalled mostly due to lack of responses.\n\n\n* jc/blame-no-follow (2012-09-21) 2 commits\n - blame: pay attention to --no-follow\n - diff: accept --no-follow option\n\n Teaches \"--no-follow\" option to \"git blame\" to disable its\n whole-file rename detection.\n\n Stalled mostly due to lack of responses.\n\n\n* jc/doc-default-format (2012-11-26) 2 commits\n - [SQAUSH] allow \"cd Doc* && make DEFAULT_DOC_TARGET=...\"\n - Allow generating a non-default set of documentation\n\n Need to address the installation half if this is to be any useful.\n\n\n* mk/maint-graph-infinity-loop (2012-09-25) 1 commit\n - graph.c: infinite loop in git whatchanged --graph -m\n\n The --graph code fell into infinite loop when asked to do what the\n code did not expect ;-)\n\n Anybody who worked on \"--graph\" wants to comment?\n Stalled mostly due to lack of responses.\n\n\n* jc/add-delete-default (2012-08-13) 1 commit\n - git add: notice removal of tracked paths by default\n\n \"git add dir/\" updated modified files and added new files, but does\n not notice removed files, which may be \"Huh?\" to some users.  They\n can of course use \"git add -A dir/\", but why should they?\n\n Resurrected from graveyard, as I thought it was a worthwhile thing\n to do in the longer term.\n\n Waiting for comments.\n\n\n* mb/remote-default-nn-origin (2012-07-11) 6 commits\n - Teach get_default_remote to respect remote.default.\n - Test that plain \"git fetch\" uses remote.default when on a detached HEAD.\n - Teach clone to set remote.default.\n - Teach \"git remote\" about remote.default.\n - Teach remote.c about the remote.default configuration setting.\n - Rename remote.c's default_remote_name static variables.\n\n When the user does not specify what remote to interact with, we\n often attempt to use 'origin'.  This can now be customized via a\n configuration variable.\n\n Expecting a re-roll.\n\n \"The first remote becomes the default\" bit is better done as a\n separate step.\n\n--------------------------------------------------\n[Cooking]\n\n* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit\n  (merged to 'next' on 2012-12-11 at 6659fdc)\n + sh-setup: work around \"unset IFS\" bug in some shells\n\n Will cook in 'next'.\n\n\n* jc/merge-blobs (2012-12-09) 4 commits\n - merge-tree: add comments to clarify what these functions are doing\n - merge-tree: lose unused \"resolve_directories\"\n - merge-tree: lose unused \"flags\" from merge_list\n - Which merge_file() function do you mean?\n\n A beginning of a new merge strategy based on the disused merge-tree\n proof-of-concept code.\n\n\n* jc/same-encoding (2012-12-10) 1 commit\n - format_commit_message(): simplify calls to logmsg_reencode()\n\n Finishing touches to the series to unify \"Do we need to reencode\n between these two encodings?\" logic.\n\n\n* nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit\n - cache-tree: invalidate i-t-a paths after generating trees\n\n Writing out a tree object when you still have intent-to-add entries\n in the index left an incorrect cache-tree data there.\n\n\n* jl/submodule-deinit (2012-12-04) 1 commit\n  (merged to 'next' on 2012-12-07 at ea772f0)\n + submodule: add 'deinit' command\n\n There was no Porcelain way to say \"I no longer am interested in\n this submodule\", once you express your interest in a submodule with\n \"submodule init\".  \"submodule deinit\" is the way to do so.\n\n Will cook in 'next'.\n\n\n* sl/git-svn-docs (2012-12-05) 4 commits\n  (merged to 'next' on 2012-12-07 at 5bfbb73)\n + git-svn: Note about tags.\n + git-svn: Expand documentation for --follow-parent\n + git-svn: Recommend use of structure options.\n + git-svn: Document branches with at-sign(@).\n\n Will cook in 'next'.\n\n\n* pf/editor-ignore-sigint (2012-12-02) 5 commits\n  (merged to 'next' on 2012-12-07 at 6b04419)\n + launch_editor: propagate signals from editor to git\n + run-command: do not warn about child death from terminal\n + launch_editor: ignore terminal signals while editor has control\n + launch_editor: refactor to use start/finish_command\n + run-command: drop silent_exec_failure arg from wait_or_whine\n\n Avoid confusing cases where the user hits Ctrl-C while in the editor\n session, not realizing git will receive the signal. Since most editors\n will take over the terminal and will block SIGINT, this is not likely\n to confuse anyone.\n\n Will cook in 'next'.\n\n\n* bc/append-signed-off-by (2012-11-26) 11 commits\n - Unify appending signoff in format-patch, commit and sequencer\n - format-patch: update append_signoff prototype\n - format-patch: stricter S-o-b detection\n - t4014: more tests about appending s-o-b lines\n - sequencer.c: teach append_signoff to avoid adding a duplicate newline\n - sequencer.c: teach append_signoff how to detect duplicate s-o-b\n - sequencer.c: always separate \"(cherry picked from\" from commit body\n - sequencer.c: recognize \"(cherry picked from ...\" as part of s-o-b footer\n - t/t3511: add some tests of 'cherry-pick -s' functionality\n - t/test-lib-functions.sh: allow to specify the tag name to test_commit\n - sequencer.c: remove broken support for rfc2822 continuation in footer\n\n Expecting a re-roll after a review.\n\n\n* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits\n  (merged to 'next' on 2012-12-03 at d677090)\n + wrap_in_html(): process message in bulk rather than line-by-line\n + wrap_in_html(): use strbuf_addstr_xml_quoted()\n + imap-send: change msg_data from storing (ptr, len) to storing strbuf\n + imap-send: correctly report errors reading from stdin\n + imap-send: store all_msgs as a strbuf\n + lf_to_crlf(): NUL-terminate msg_data::data\n + xml_entities(): use function strbuf_addstr_xml_quoted()\n + Add new function strbuf_add_xml_quoted()\n\n Update imap-send to reuse xml quoting code from http-push codepath,\n clean up some code, and fix a small bug.\n\n Will cook in 'next'.\n\n\n* jc/doc-maintainer (2012-11-27) 1 commit\n - update \"howto maintain git\"\n\n An early draft that is still incomplete.\n\n\n* jk/fsck-dot-in-trees (2012-11-28) 2 commits\n  (merged to 'next' on 2012-11-28 at 519dabc)\n + fsck: warn about \".git\" in trees\n + fsck: warn about '.' and '..' in trees\n\n Will cook in 'next'.\n\n\n* mh/doc-remote-helpers (2012-12-07) 6 commits\n  (merged to 'next' on 2012-12-07 at 7ac8c25)\n + git-remote-helpers.txt: clarify options & ref list attributes\n + git-remote-helpers.txt: clarify command <-> capability correspondences\n + git-remote-helpers.txt: rearrange description of capabilities\n + git-remote-helpers.txt: minor grammar fix\n + git-remote-helpers.txt: document missing capabilities\n + git-remote-helpers.txt: document invocation before input format\n\n Will merge to 'master'.\n\n\n* mh/pthreads-autoconf (2012-11-27) 1 commit\n  (merged to 'next' on 2012-11-28 at 780600e)\n + configure.ac: fix pthreads detection on Mac OS X\n\n Will cook in 'next'.\n\n\n* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits\n  (merged to 'next' on 2012-11-28 at 43d51c2)\n + config: exit on error accessing any config file\n + doc: advertise GIT_CONFIG_NOSYSTEM\n + config: treat user and xdg config permission problems as errors\n + config, gitignore: failure to access with ENOTDIR is ok\n\n An RFC to deal with a situation where .config/git is a file and we\n notice .config/git/config is not readable due to ENOTDIR, not\n ENOENT.\n\n Will cook in 'next'.\n\n\n* mh/ceiling (2012-10-29) 8 commits\n  (merged to 'next' on 2012-11-26 at d1ce76a)\n + string_list_longest_prefix(): remove function\n + setup_git_directory_gently_1(): resolve symlinks in ceiling paths\n + longest_ancestor_length(): require prefix list entries to be normalized\n + longest_ancestor_length(): take a string_list argument for prefixes\n + longest_ancestor_length(): use string_list_split()\n + Introduce new function real_path_if_valid()\n + real_path_internal(): add comment explaining use of cwd\n + Introduce new static function real_path_internal()\n\n Elements of GIT_CEILING_DIRECTORIES list may not match the real\n pathname we obtain from getcwd(), leading the GIT_DIR discovery\n logic to escape the ceilings the user thought to have specified.\n\n Resurrected from Stalled; the earlier performance fear was\n unwarranted.\n\n Will cook in 'next'.\n\n\n* fc/fast-export-fixes (2012-12-03) 15 commits\n  (merged to 'next' on 2012-12-03 at f9df523)\n + fast-export: make sure updated refs get updated\n + fast-export: don't handle uninteresting refs\n + fast-export: fix comparison in tests\n + fast-export: trivial cleanup\n + remote-testgit: implement the \"done\" feature manually\n + remote-testgit: report success after an import\n + remote-testgit: exercise more features\n + remote-testgit: cleanup tests\n + remote-testgit: remove irrelevant test\n + remote-testgit: remove non-local functionality\n + Add new simplified git-remote-testgit\n + Rename git-remote-testgit to git-remote-testpy\n + remote-helpers: fix failure message\n + remote-testgit: fix direction of marks\n + fast-export: avoid importing blob marks\n\n Will cook in 'next'.\n\n\n* jc/apply-trailing-blank-removal (2012-10-12) 1 commit\n  (merged to 'next' on 2012-11-26 at 3af69e7)\n + apply.c:update_pre_post_images(): the preimage can be truncated\n\n Fix to update_pre_post_images() that did not take into account the\n possibility that whitespace fix could shrink the preimage and\n change the number of lines in it.\n\n Will cook in 'next'.\n\n\n* nd/pathspec-wildcard (2012-11-26) 4 commits\n  (merged to 'next' on 2012-12-03 at eca0fcb)\n + tree_entry_interesting: do basedir compare on wildcard patterns when possible\n + pathspec: apply \"*.c\" optimization from exclude\n + pathspec: do exact comparison on the leading non-wildcard part\n + pathspec: save the non-wildcard length part\n\n Will cook in 'next'.\n\n\n* nd/wildmatch (2012-11-20) 14 commits\n  (merged to 'next' on 2012-11-21 at 151288f)\n + test-wildmatch: avoid Windows path mangling\n  (merged to 'next' on 2012-10-25 at 510e8df)\n + Support \"**\" wildcard in .gitignore and .gitattributes\n + wildmatch: make /**/ match zero or more directories\n + wildmatch: adjust \"**\" behavior\n + wildmatch: fix case-insensitive matching\n + wildmatch: remove static variable force_lower_case\n + wildmatch: make wildmatch's return value compatible with fnmatch\n + t3070: disable unreliable fnmatch tests\n + Integrate wildmatch to git\n + wildmatch: follow Git's coding convention\n + wildmatch: remove unnecessary functions\n + Import wildmatch from rsync\n + ctype: support iscntrl, ispunct, isxdigit and isprint\n + ctype: make sane_ctype[] const array\n\n Allows pathname patterns in .gitignore and .gitattributes files\n with double-asterisks \"foo/**/bar\" to match any number of directory\n hierarchies.\n\n I suspect that this needs to be plugged to pathspec matching code;\n otherwise \"git log -- 'Docum*/**/*.txt'\" would not show the log for\n commits that touch Documentation/git.txt, which would be confusing\n to the users.\n\n Will cook in 'next'.\n\n\n* cr/push-force-tag-update (2012-12-03) 10 commits\n  (merged to 'next' on 2012-12-04 at af2e3a9)\n + push: allow already-exists advice to be disabled\n + push: rename config variable for more general use\n + push: cleanup push rules comment\n + push: clarify rejection of update to non-commit-ish\n + push: require force for annotated tags\n + push: require force for refs under refs/tags/\n + push: flag updates that require force\n + push: keep track of \"update\" state separately\n + push: add advice for rejected tag reference\n + push: return reject reasons as a bitset\n\n Require \"-f\" for push to update a tag, even if it is a fast-forward.\n\n Will cook in 'next'.\n"},{"id":"204823","messageId":"CAMP44s2DAuhk5FkDm0-cYsikY0o6vuZ4FyAnXhbtsgqKQF1dpg@mail.gmail.com","threadId":"32327","inReplyTo":"7vhanq257s.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-13T06:08:48Z","receivedAt":"2012-12-13T06:08:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Dec 12, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> [Stalled]\n>\n> * fc/remote-bzr (2012-11-28) 10 commits\n>  - (fixup) test-bzr.sh: fix multi-line string assignment\n>  - remote-bzr: detect local repositories\n>  - remote-bzr: add support for older versions of bzr\n>  - remote-bzr: add support to push special modes\n>  - remote-bzr: add support for fecthing special modes\n>  - remote-bzr: add simple tests\n>  - remote-bzr: update working tree\n>  - remote-bzr: add support for remote repositories\n>  - remote-bzr: add support for pushing\n>  - Add new remote-bzr transport helper\n>\n>  New remote helper for bzr (v3).  With minor fixes, this may be ready\n>  for 'next'.\n\nWhat minor fixes?\n\n-- \nFelipe Contreras\n"},{"id":"204826","messageId":"7vvcc6z801.fsf@alter.siamese.dyndns.org","threadId":"32327","inReplyTo":"CAMP44s2DAuhk5FkDm0-cYsikY0o6vuZ4FyAnXhbtsgqKQF1dpg@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T08:11:42Z","receivedAt":"2012-12-13T08:11:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Wed, Dec 12, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> [Stalled]\n>>\n>> * fc/remote-bzr (2012-11-28) 10 commits\n>>  - (fixup) test-bzr.sh: fix multi-line string assignment\n>>  - remote-bzr: detect local repositories\n>>  - remote-bzr: add support for older versions of bzr\n>>  - remote-bzr: add support to push special modes\n>>  - remote-bzr: add support for fecthing special modes\n>>  - remote-bzr: add simple tests\n>>  - remote-bzr: update working tree\n>>  - remote-bzr: add support for remote repositories\n>>  - remote-bzr: add support for pushing\n>>  - Add new remote-bzr transport helper\n>>\n>>  New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>  for 'next'.\n>\n> What minor fixes?\n\nLookng at the above (fixup), $gmane/210744 comes to mind, but there\nmay be others.  It is the responsibility of a contributor to keep\ntrack of review comments others give to his or her patches and\nreroll them, so I do not recall every minor details, sorry.\n"},{"id":"204827","messageId":"CAMP44s3uyC0V6ycTv78mG36_i7ugMLwwNk2cqNZatEJuL7Ee1w@mail.gmail.com","threadId":"32327","inReplyTo":"7vvcc6z801.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-13T10:08:17Z","receivedAt":"2012-12-13T10:08:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n>>>  New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>  for 'next'.\n>>\n>> What minor fixes?\n>\n> Lookng at the above (fixup), $gmane/210744 comes to mind\n\nThat doesn't matter. The code and the tests would work just fine.\n\n> but there may be others.  It is the responsibility of a contributor to keep\n> track of review comments others give to his or her patches and\n> reroll them, so I do not recall every minor details, sorry.\n\nThere is nothing that prevents remote-bzr from being merged.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204828","messageId":"BF9B1394-0321-4F1C-AD1B-F40D02DBE71A@quendi.de","threadId":"32327","inReplyTo":"CAMP44s3uyC0V6ycTv78mG36_i7ugMLwwNk2cqNZatEJuL7Ee1w@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Max Horn","fromEmail":"postbox@quendi.de","sentAt":"2012-12-13T12:04:32Z","receivedAt":"2012-12-13T12:04:32Z","isPatch":false,"sender":{"key":"postbox@quendi.de","avatar":null},"body":"\nOn 13.12.2012, at 11:08, Felipe Contreras wrote:\n\n> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n>>>> New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>> for 'next'.\n>>> \n>>> What minor fixes?\n>> \n>> Lookng at the above (fixup), $gmane/210744 comes to mind\n> \n> That doesn't matter. The code and the tests would work just fine.\n\n\nIt doesn't matter? I find that statement hard to align with what the maintainer of git, and thus the person who decides whether your patch series gets merged or not, wrote just above? In fact, it seems to me that what Junio said matters a great deal...\n\nThis is a very strange attitude...\n\nIn another email, you complained about nobody reviewing your patches respectively nobody voicing any constructive criticism. Yet Junio did just that, and again in $gmane/210745 -- and you replied to neither, and acted on neither (not even by refuting the points brought up), and now summarily dismiss them as irrelevant. I find that quite disturbing :-(.\n\n> \n>> but there may be others.  It is the responsibility of a contributor to keep\n>> track of review comments others give to his or her patches and\n>> reroll them, so I do not recall every minor details, sorry.\n> \n> There is nothing that prevents remote-bzr from being merged.\n\nWell, I think that is up to Junio to decide in the end, though :-). He wrote \n\n\nCheers,\nMax"},{"id":"204847","messageId":"CAMP44s3Es-rLjwe6sgOi9OmwQouM4AbFKAbGB5UgS6sUtYRgKQ@mail.gmail.com","threadId":"32327","inReplyTo":"BF9B1394-0321-4F1C-AD1B-F40D02DBE71A@quendi.de","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-13T19:06:36Z","receivedAt":"2012-12-13T19:06:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote:\n>\n> On 13.12.2012, at 11:08, Felipe Contreras wrote:\n>\n>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>>>> New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>>> for 'next'.\n>>>>\n>>>> What minor fixes?\n>>>\n>>> Lookng at the above (fixup), $gmane/210744 comes to mind\n>>\n>> That doesn't matter. The code and the tests would work just fine.\n>\n>\n> It doesn't matter? I find that statement hard to align with what the maintainer of git, and thus the person who decides whether your patch series gets merged or not, wrote just above? In fact, it seems to me that what Junio said matters a great deal...\n\nSo you think Junio knows more about remote-bzr than I do? I repeat; it\ndoesn't affect the tests, it doesn't affect the code, it doesn't cause\nany problem. remote-bzr could be merged today, in fact, it could have\nbeen merged a month ago.\n\nYou don't trust me? Here, look:\n\n\tcmd=<<EOF\n\timport bzrlib\n\tbzrlib.initialize()\n\timport bzrlib.plugin\n\tbzrlib.plugin.load_plugins()\n\timport bzrlib.plugins.fastimport\n\tEOF\n\n\tif ! \"$PYTHON_PATH\" -c \"$cmd\"; then\n\t\techo \"consider setting BZR_PLUGIN_PATH=$HOME/.bazaar/plugins\" 1>&2\n\t\tskip_all='skipping remote-bzr tests; bzr-fastimport not available'\n\t\ttest_done\n\tfi\n\nAll this code is a no-op, because, as Junio pointed out, cmd is null.\nHow is that a problem? It's not. The first version of remote-bzr\nrelied on the bazaar fastimport plug-in, so this check was needed, in\ncase you had bazaar, but not this particular plug-in, but today\nremote-bzr doesn't need this plug-in, so this chunk of code should be\nremoved. The fact that this code does nothing (because python -c ''\ndoes nothing) is *not a problem*.\n\nIn fact, even if that code failed 100% of the time, it wouldn't hurt\nanybody, because 'make -C t' would work, everything would work, the\nonly thing that would fail is 'make -C contrib/remote-helpers/\ntest-bzr', which very very few people would consider a problem. But it\ndoesn't fail, it works.\n\nWho benefits by delaying the merging of this code? Nobody. Who gets\nhurt? The users, of course.\n\n> This is a very strange attitude...\n>\n> In another email, you complained about nobody reviewing your patches respectively nobody voicing any constructive criticism. Yet Junio did just that, and again in $gmane/210745 -- and you replied to neither, and acted on neither (not even by refuting the points brought up), and now summarily dismiss them as irrelevant. I find that quite disturbing :-(.\n\nI didn't say it was irrelevant, it should be fixed, but Junio said\n\"With minor fixes, this may be ready for 'next'.\" which is no true\nIMO, it's ready *now*, it was ready one month ago. For 'next', this\nproblem doesn't matter.\n\nThe feedback is appreciated, but delaying the merging of this code for\nno reason makes little sense to me. Junio, of course, can do whatever\nhe wants. The removal of this no-op code can wait, or it can be done\non top of v3, there's no need for re-roll, and Junio already\ncomplained about the v3 re-roll.\n\nAnd I didn't act because I was on vacations, git development is not my\nonly priority. And even if I had time, I don't see why I should\nprioritize this fix, it's not important, the code is ready.\n\n>>> but there may be others.  It is the responsibility of a contributor to keep\n>>> track of review comments others give to his or her patches and\n>>> reroll them, so I do not recall every minor details, sorry.\n>>\n>> There is nothing that prevents remote-bzr from being merged.\n>\n> Well, I think that is up to Junio to decide in the end, though :-). He wrote\n\nNo. He can decide if the code gets merged, but he is not the voice of\ntruth. Nothing prevents him from merging the code, except himself.\nThere is no known issue with the code, that is a true fact.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204849","messageId":"7vmwxhycii.fsf@alter.siamese.dyndns.org","threadId":"32327","inReplyTo":"CAMP44s3uyC0V6ycTv78mG36_i7ugMLwwNk2cqNZatEJuL7Ee1w@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T19:31:49Z","receivedAt":"2012-12-13T19:31:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>>>>  New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>>  for 'next'.\n>>>\n>>> What minor fixes?\n>>\n>> Lookng at the above (fixup), $gmane/210744 comes to mind\n>\n> That doesn't matter. The code and the tests would work just fine.\n\nOne of us must be very confused.  Perhaps you were looking at a\nwrong message (or I quoted a wrong one?).\n\n  ... goes and double checks ...\n\nOne of the review points were about this piece in the test:\n\n    > +cmd=<<EOF\n    > +import bzrlib\n    > +bzrlib.initialize()\n    > +import bzrlib.plugin\n    > +bzrlib.plugin.load_plugins()\n    > +import bzrlib.plugins.fastimport\n    > +EOF\n    > +if ! \"$PYTHON_PATH\" -c \"$cmd\"; then\n\n    I cannot see how this could have ever worked.\n\nAnd I still don't see how your \"would work just fine\" can be true.\n\n>> but there may be others.  It is the responsibility of a contributor to keep\n>> track of review comments others give to his or her patches and\n>> reroll them, so I do not recall every minor details, sorry.\n\nThere may be others, but $gmane/210745 is also relevant, I think.\n\n> There is nothing that prevents remote-bzr from being merged.\n\nWhat we merge may not be perfect.  Bugs and misdesigns are often\nidentified long after a topic is merged and it is perfectly normal\nwe fix things up in-tree.  There are even times where we say \"OK, it\nis known to break if the user does something that pokes this and\nthat obscure corners of this code, but the benefit of merging this\n99% working code to help users that do not exercise the rare cases\nis greater than having them wait for getting the remaining 1% right,\nso let's merge it with known breakage documentation\".\n\nBut it is totally a different matter to merge a crap with known\nbreakage that is one easy fix away from the get-go.  Allowing that\nmeans that all the times we spend on reviewing patches here go\nwasted, discouraging reviewers.\n\nIf you want others to take your patches with respect, please take\nreviewers' comments with the same respect you expect to be paid by\nothers.\n"},{"id":"204853","messageId":"CAMP44s0qK6yNiPe0ERDJWK-wfm3DdXZYwRzisoCPJ7PjsdkObQ@mail.gmail.com","threadId":"32327","inReplyTo":"7vmwxhycii.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-13T22:05:08Z","receivedAt":"2012-12-13T22:05:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>>>>  New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>>>  for 'next'.\n>>>>\n>>>> What minor fixes?\n>>>\n>>> Lookng at the above (fixup), $gmane/210744 comes to mind\n>>\n>> That doesn't matter. The code and the tests would work just fine.\n>\n> One of us must be very confused.  Perhaps you were looking at a\n> wrong message (or I quoted a wrong one?).\n>\n>   ... goes and double checks ...\n>\n> One of the review points were about this piece in the test:\n>\n>     > +cmd=<<EOF\n>     > +import bzrlib\n>     > +bzrlib.initialize()\n>     > +import bzrlib.plugin\n>     > +bzrlib.plugin.load_plugins()\n>     > +import bzrlib.plugins.fastimport\n>     > +EOF\n>     > +if ! \"$PYTHON_PATH\" -c \"$cmd\"; then\n>\n>     I cannot see how this could have ever worked.\n>\n> And I still don't see how your \"would work just fine\" can be true.\n\nAs I have explained, all this code is the equivalent of python -c '',\nor rather, it's a no-op. It works in the sense that it doesn't break\nanything.\n\nThe purpose of the code is to check for the fastimport plug-in, but\nthat plug-in is not used any more, it's vestigial code, it doesn't\nmatter if the check works or not, as long as it doesn't fail.\n\n>>> but there may be others.  It is the responsibility of a contributor to keep\n>>> track of review comments others give to his or her patches and\n>>> reroll them, so I do not recall every minor details, sorry.\n>\n> There may be others, but $gmane/210745 is also relevant, I think.\n\nI'll comment on the patch, but I don't think it really prevents the merge.\n\n>> There is nothing that prevents remote-bzr from being merged.\n>\n> What we merge may not be perfect.  Bugs and misdesigns are often\n> identified long after a topic is merged and it is perfectly normal\n> we fix things up in-tree.  There are even times where we say \"OK, it\n> is known to break if the user does something that pokes this and\n> that obscure corners of this code, but the benefit of merging this\n> 99% working code to help users that do not exercise the rare cases\n> is greater than having them wait for getting the remaining 1% right,\n> so let's merge it with known breakage documentation\".\n>\n> But it is totally a different matter to merge a crap with known\n> breakage that is one easy fix away from the get-go.  Allowing that\n> means that all the times we spend on reviewing patches here go\n> wasted, discouraging reviewers.\n\nThere is no breakage.\n\n> If you want others to take your patches with respect, please take\n> reviewers' comments with the same respect you expect to be paid by\n> others.\n\nI don't need others to take my patches with respect, my patches are\nnot people, they don't have feelings.\n\nThat being said, I don't think I have disrespected any of your\ncomments. Yes, you are right that the above code is wrong and doesn't\ndo anything, what part of agreeing is disrespectful? But I don't agree\nthat it is a merge blocker. Disagreeing is not disrespecting.\n\nThis code was ready for 1.8.1, but it's not going to be there, so, I\ndon't see any hurry. As I said, I think the code is ready, and these\nminor details can wait.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204857","messageId":"7vsj79wmck.fsf@alter.siamese.dyndns.org","threadId":"32327","inReplyTo":"CAMP44s0qK6yNiPe0ERDJWK-wfm3DdXZYwRzisoCPJ7PjsdkObQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T23:42:19Z","receivedAt":"2012-12-13T23:42:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> One of the review points were about this piece in the test:\n>>\n>>     > +cmd=<<EOF\n>>     > +import bzrlib\n>>     > +bzrlib.initialize()\n>>     > +import bzrlib.plugin\n>>     > +bzrlib.plugin.load_plugins()\n>>     > +import bzrlib.plugins.fastimport\n>>     > +EOF\n>>     > +if ! \"$PYTHON_PATH\" -c \"$cmd\"; then\n>>\n>>     I cannot see how this could have ever worked.\n>>\n>> And I still don't see how your \"would work just fine\" can be true.\n>\n> As I have explained, all this code is the equivalent of python -c '',\n> or rather, it's a no-op. It works in the sense that it doesn't break\n> anything.\n\nAren't you ashamed of yourself after having said this?\n\n> The purpose of the code is to check for the fastimport plug-in, but\n> that plug-in is not used any more, it's vestigial code, it doesn't\n> matter if the check works or not, as long as it doesn't fail.\n\nIf so, the final version that is suitable for merging would have\nthat unused code stripped away, no?\n\n>> But it is totally a different matter to merge a crap with known\n>> breakage that is one easy fix away from the get-go.  Allowing that\n>> means that all the times we spend on reviewing patches here go\n>> wasted, discouraging reviewers.\n>\n> There is no breakage.\n\nUnused code that burdens others to read through to make sure nothing\nis broken is already broken from maintenance point of view.\n\nWhy are you wasting my time and everybody's bandwidth on this, when\nyou are very well capable of rerolling the series with removal and\nstyle fixes in far shorter time?\n"},{"id":"204862","messageId":"CAMP44s3QtOssBDW_XRJR_K0N-rpwQ4mFx-8e2c6pUc-UkoGb1A@mail.gmail.com","threadId":"32327","inReplyTo":"7vsj79wmck.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-14T00:50:50Z","receivedAt":"2012-12-14T00:50:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 13, 2012 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> ...\n>>> One of the review points were about this piece in the test:\n>>>\n>>>     > +cmd=<<EOF\n>>>     > +import bzrlib\n>>>     > +bzrlib.initialize()\n>>>     > +import bzrlib.plugin\n>>>     > +bzrlib.plugin.load_plugins()\n>>>     > +import bzrlib.plugins.fastimport\n>>>     > +EOF\n>>>     > +if ! \"$PYTHON_PATH\" -c \"$cmd\"; then\n>>>\n>>>     I cannot see how this could have ever worked.\n>>>\n>>> And I still don't see how your \"would work just fine\" can be true.\n>>\n>> As I have explained, all this code is the equivalent of python -c '',\n>> or rather, it's a no-op. It works in the sense that it doesn't break\n>> anything.\n>\n> Aren't you ashamed of yourself after having said this?\n\nIt is a fact.\n\n>> The purpose of the code is to check for the fastimport plug-in, but\n>> that plug-in is not used any more, it's vestigial code, it doesn't\n>> matter if the check works or not, as long as it doesn't fail.\n>\n> If so, the final version that is suitable for merging would have\n> that unused code stripped away, no?\n\nTo the users there's absolutely no difference.\n\n>>> But it is totally a different matter to merge a crap with known\n>>> breakage that is one easy fix away from the get-go.  Allowing that\n>>> means that all the times we spend on reviewing patches here go\n>>> wasted, discouraging reviewers.\n>>\n>> There is no breakage.\n>\n> Unused code that burdens others to read through to make sure nothing\n> is broken is already broken from maintenance point of view.\n\nRemove the whole test then. I'm already doing way more than most of\nthe code in contrib by providing tests.\n\n> Why are you wasting my time and everybody's bandwidth on this, when\n> you are very well capable of rerolling the series with removal and\n> style fixes in far shorter time?\n\nI will do that, when I do that.\n\nWe have no time constraints, have we? This code is not getting in\n1.8.1 either way.\n\nAnyway, if you merge this code as it is, nothing bad will happen.\nNobody would get hurt, and in fact, very few, if anybody, would\nnotice.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204868","messageId":"F151B265-7E3E-4989-AA16-EB7CAC298126@quendi.de","threadId":"32327","inReplyTo":"CAMP44s3Es-rLjwe6sgOi9OmwQouM4AbFKAbGB5UgS6sUtYRgKQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Max Horn","fromEmail":"postbox@quendi.de","sentAt":"2012-12-14T13:11:40Z","receivedAt":"2012-12-14T13:11:40Z","isPatch":false,"sender":{"key":"postbox@quendi.de","avatar":null},"body":"Felipe,\n\nplease stop referring to \"facts\" and \"obvious\". You pretend to be a being of pure reason and that everything you say is logical, drawn from facts. But you forget or perhaps do not know that logic by itself proofs nothing, it all depends on the axioms you impose. And yours are quite different from what others consider as such, and apparently also inconsistent. \n\nSo, instead of trying to twist things around so that broken things in your code are not broken after all, why not simply re-roll your patch with the \"obvious\" fixes applies? As you write yourself, time is not pressing at all -- so I don't see why your patch should be merged now, and fixed later, contrary to how other people's patches are treated? Why not fix them first, and then apply? We do have time, after all! And nobody is expecting you to do that while you are on vacation, either. Nor that you do it instantly.\n\nJust say: \"OK, I see there is a problem with the patches; even though I consider it unimportant, I will play by the rules everybody here has to follow, and re-roll the patch series. But this is of low priority for me, so I cannot say right now when it will happen\".\n\nEverybody would be happy then. Except perhaps the hypothetical users, who would have to wait a bit longer -- but oh, not really, because they can just use remote-bzr from your repo, yay :-). I really like that about it, it lives in contrib, so one can use it w/o it being merged into git.git.\n\nInstead, you make claims that make you look like a foolish and arrogant ass, all the while insulting Junio and me implicitly. Why do you do that??? It delays acceptance of your nice work. As you write, this hurts the users. So why do it?\n\n\nSince you keep complaining that nobody ever really can point to anything wrong your said, I'll do you the favor by deconstructing one of the claims you made:\n\n\nOn 13.12.2012, at 20:06, Felipe Contreras wrote:\n\n> On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote:\n>> \n>> On 13.12.2012, at 11:08, Felipe Contreras wrote:\n>> \n>>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>> \n>>>>>> New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>>>> for 'next'.\n>>>>> \n>>>>> What minor fixes?\n>>>> \n>>>> Lookng at the above (fixup), $gmane/210744 comes to mind\n>>> \n>>> That doesn't matter. The code and the tests would work just fine.\n>> \n>> \n>> It doesn't matter? I find that statement hard to align with what the maintainer of git, and thus the person who decides whether your patch series gets merged or not, wrote just above? In fact, it seems to me that what Junio said matters a great deal...\n> \n> So you think Junio knows more about remote-bzr than I do?\n\n\nThis is a classical straw man argument. No, I do not think that. But I do think that Junio knows enough to review your code, and I do think that the point he raised is valid. You disagree with the importance of his point\n\n> I repeat; it\n> doesn't affect the tests, it doesn't affect the code, it doesn't cause\n> any problem. remote-bzr could be merged today, in fact, it could have\n> been merged a month ago.\n> \n> You don't trust me? Here, look:\n> \n[..]\n\n> All this code is a no-op, because, as Junio pointed out, cmd is null.\n> How is that a problem? It's not.\n\nIt is a problem. Because either the code inside the if is important, and then this is a bug. Or it is not important -- then it should not be there in the first place.\n\nEither way, the patch series should be re-rolled. Of course in a whatever time frame suits you. If you are not willing to do that, this is sad, but of course also your right!\n\n[...]\n\n>> This is a very strange attitude...\n>> \n>> In another email, you complained about nobody reviewing your patches respectively nobody voicing any constructive criticism. Yet Junio did just that, and again in $gmane/210745 -- and you replied to neither, and acted on neither (not even by refuting the points brought up), and now summarily dismiss them as irrelevant. I find that quite disturbing :-(.\n> \n> I didn't say it was irrelevant, it should be fixed,\n\nActually, you wrote:\n\n \"That doesn't matter.\"\n\nSo I paraphrased. In any case, I am glad to hear you finally agree that it should be fixed (which you did *not* say in your initial reply). So the problem we have seems to be that you do not understand how patches typically handled in git.git. Well, based on my observation: If reviews point out things in a patch series that are not optimal or even broken, it is expected that the submitter fixes this locally and resubmits a new version of the series. In some cases, it is possible to make exceptions, e.g. trivial typo fixes can be applied on the fly. But otherwise, you re-roll, you do not get your stuff merged just based on the promise that you'll submit a series of fixes later. Esp. if the fixes are relatively easy. \n\nOf course more exceptions can be made, but based on what I saw, this is rare, and has to be justified quite well. I fail to see a justification in this case... You mentioned \"the users\" but AFAIK there are no known users yet, and even if, they can simply use remote-bzr from your tree.\n\nThis could perhaps be documented explicitly in Documentation/SubmittingPatches. Not sure if I think this would be a good idea or even helpful, just thinking out aloud.\n\n\n> but Junio said\n> \"With minor fixes, this may be ready for 'next'.\" which is no true\n> IMO, it's ready *now*, it was ready one month ago. For 'next', this\n> problem doesn't matter.\n> \n> The feedback is appreciated, but delaying the merging of this code for\n> no reason makes little sense to me.\n\nAnd here goes the insult. You say Junio has no reason to delay the merging. When you really mean that you don't agree with his reasons. So you attack his professionalism and integrity by alluding that he has some ulterior motives to delay the patch. E.g. that he is hates you, is just mean, does it out of stubbornness, etc.\n\n> Junio, of course, can do whatever he wants. The removal of this no-op code can wait, or it can be done\n> on top of v3, there's no need for re-roll, and Junio already\n> complained about the v3 re-roll.\n> \n> And I didn't act because I was on vacations, git development is not my\n> only priority.\n\nOf course. Nobody is complaining that you take too long to reply. We are just unhappy in the way you reply when you do reply :-(.\n\n\n> And even if I had time, I don't see why I should\n> prioritize this fix, it's not important, the code is ready.\n\nAnother straw man: Nobody asked you to prioritize the fix, take your time. It was you who asked that the series should be applied without any further fixes. \n\n\n> \n>>>> but there may be others.  It is the responsibility of a contributor to keep\n>>>> track of review comments others give to his or her patches and\n>>>> reroll them, so I do not recall every minor details, sorry.\n>>> \n>>> There is nothing that prevents remote-bzr from being merged.\n>> \n>> Well, I think that is up to Junio to decide in the end, though :-). He wrote\n> \n> No. He can decide if the code gets merged, but he is not the voice of\n> truth. Nothing prevents him from merging the code, except himself.\n> There is no known issue with the code, that is a true fact.\n\nHere are a multitude of fallacies hidden, partially explainable by a differing set of axioms, and/or shear arrogance.\n\nLet us re-reread what was said: Initially, you claimed that \"There is nothing that prevents remote-bzr from being merged\".\n\nNow, it wasn't said in the above, but let me make it explicit: This statement is \"obviously\"[1] wrong. There are parts of the patch series Junio thinks are not up to par, and he made it quite clear that he will not merge it until these things are resolved.\n\nHence, ignoring all else, there obviously *is* something that prevents remote-bzr from being merged. That is a \"fact\". You even admit so yourself, also contradicting yourself:\n\n  \"Nothing prevents him from merging the code, except himself.\"\n\n\nSo how is it possible that you can claim that there is nothing that prevents the merge? Ignoring the self-contradicting aspects of what you wrote, the basis for your differing conclusion seems to be that you change the terms of discussion and are using a different set of axioms. In particular, you apparently redefine\n  \"things that prevent remote-bzr from being merged\"\nas\n  \"things that in Felipe's view prevent remote-bzr from being merged\".\n\n\nOf course one can arbitrarily bend the rules by this definition. For example, we could redefine \"nothing prevents the merge\" as\n \"no technical reasons prevent the merge\", and the latter is indeed quite true; your patch series applies perfectly fine, git can do that. Of course the same holds for a patch which removes git.c from the repository, so I don't think this definition is particularly useful...\n\n\nBack to your self-contradictory statement: It could be parsed as an (not well-formed) attempt to say that Junio has no objective reasons to reject your patch. I.e. you again imply that Junio's decision that the patch is not merge-ready is not based upon \"logical conclusions from the given set of facts\".  Indeed, I would dare say that many people on the list will have interpreted your statements this way... At least I did.\n\nThis is something what a lot of people would consider a strong insult towards the professionalism and integrity of Junio. There are more examples of this in previous communications between you and other people in the list. \n\nYou finally add \"There is no known issue with the code, that is a true fact.\". Within your axiom set, this is certainly true. It certainly is not true in mine or Junio's... Yet you very strongly emphasis with your statement that your set of axioms is the correct one to use here, although I would guess that most people would disagree.\n\n\nThis is especially arrogant in view of the another straw man argument you are employing: By writing \"[Junio] he is not the voice of truth.\", you implicate that I or anybody were of this opinion. But I am not, and what I wrote cannot logically be construed as saying so. At least not within what most people would consider as axiom set; of course if your axiom set includes \"Max believes Junio is the voice of truth\", your claim because truth, albeit a tautological one. But let me make clear that any such axioms, or set of axioms leading to that implicating, are inconsistent: In my view, of course Junio is fallible and makes mistakes, and can be wrong etc. -- like any human being. Including most definitely me and you.\n\n\n\nThis is a horrible way of working within a team effort :-(. I find this a great pity, because I believe you are doing some really nice work, I esp. like your remote-hg which works much better for me than the others I tried so far.\n\n\nBye,\nMax\n\n\n[1]  As a mathematician, I was taught to avoid the word \"obvious\" in any written form of proof, as it makes you sound arrogant, and it also discourages the reader from thinking critical about a statement, which is considered extremely bad. But since you like it so much, I am using here on purpose.\n"},{"id":"204893","messageId":"CAMP44s0r_KAKt7Lm1cdumN1cOWzjab3ruYqxp-s6OR1g1qqbcQ@mail.gmail.com","threadId":"32327","inReplyTo":"F151B265-7E3E-4989-AA16-EB7CAC298126@quendi.de","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-15T03:14:36Z","receivedAt":"2012-12-15T03:14:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Dec 14, 2012 at 7:11 AM, Max Horn <postbox@quendi.de> wrote:\n\n> please stop referring to \"facts\" and \"obvious\". You pretend to be a being of pure reason and that everything you say is logical, drawn from facts. But you forget or perhaps do not know that logic by itself proofs nothing, it all depends on the axioms you impose. And yours are quite different from what others consider as such, and apparently also inconsistent.\n\nWhen I say something is a fact, I do mean it. It's not my opinion,\nit's not what I think, it's a fact. The Earth revolves around the Sun,\nJunio is the maintainer, Junio can merge whatever he wants, those are\nfacts.\n\nIf you think the Earth revolving around the Sun is not a fact, that's\nyour choice, but if you want to convince others that this is not a\nfact, you need to show *why*.\n\n> So, instead of trying to twist things around so that broken things in your code are not broken after all, why not simply re-roll your patch with the \"obvious\" fixes applies?\n\nFirst of all, it depends on your definition of \"broken\". To me\nsomething broken is something that does not *work*. The code works,\nthe tests have some cruft in it, but it *works*, it's not broken.\n\nAnd I said multiple times now that I WILL FIX IT. I'm not going to\nrepeat it again, and quite frankly, I don't think I'm going to reply\nto this thread any more. What makes you think that you owe my free\ntime? I do with my free time whatever I want. I will fix it, when I\nfeel like fixing it. This code will not go into 1.8.1, so there's no\npoint hurrying the fix, I have other things to do.\n\n> As you write yourself, time is not pressing at all -- so I don't see why your patch should be merged now, and fixed later, contrary to how other people's patches are treated? Why not fix them first, and then apply? We do have time, after all! And nobody is expecting you to do that while you are on vacation, either. Nor that you do it instantly.\n\nTime is not pressing because Junio decided not to merge, and he\ndecided not to merge, because of this \"issue\". This hurts users, and\nbenefits no one.\n\n> Just say: \"OK, I see there is a problem with the patches; even though I consider it unimportant, I will play by the rules everybody here has to follow, and re-roll the patch series. But this is of low priority for me, so I cannot say right now when it will happen\".\n\nThat is what I said. What part of \"I didn't say it was irrelevant, it\nshould be fixed\" didn't you understand? And no, this is not a \"rule\",\nyou assume it *must* be re-rolled, it doesn't.\n\n> Everybody would be happy then. Except perhaps the hypothetical users, who would have to wait a bit longer -- but oh, not really, because they can just use remote-bzr from your repo, yay :-). I really like that about it, it lives in contrib, so one can use it w/o it being merged into git.git.\n\nIt's not because of me that users would have to wait, it was Junio's\ndecision, there was literally nothing I could do, before, or now, for\nthis code to be merged for 1.8.1. And yes, people can use my repo *if*\nthey know about it, most people just follow the mainline, and many\ndon't even read the news.\n\n> Instead, you make claims that make you look like a foolish and arrogant ass, all the while insulting Junio and me implicitly. Why do you do that??? It delays acceptance of your nice work. As you write, this hurts the users. So why do it?\n\nShow me *exactly* where I insulted anybody, and show me where I made a\nfalse claim. And no, this discussion doesn't delay the acceptance, the\nacceptance was already delayed before this discussion, there was\nnothing I could do, neither in the past or present.\n\n> Since you keep complaining that nobody ever really can point to anything wrong your said, I'll do you the favor by deconstructing one of the claims you made:\n\nPlease.\n\n> On 13.12.2012, at 20:06, Felipe Contreras wrote:\n>\n>> On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote:\n>>>\n>>> On 13.12.2012, at 11:08, Felipe Contreras wrote:\n>>>\n>>>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>>\n>>>>>>> New remote helper for bzr (v3).  With minor fixes, this may be ready\n>>>>>>> for 'next'.\n>>>>>>\n>>>>>> What minor fixes?\n>>>>>\n>>>>> Lookng at the above (fixup), $gmane/210744 comes to mind\n>>>>\n>>>> That doesn't matter. The code and the tests would work just fine.\n>>>\n>>>\n>>> It doesn't matter? I find that statement hard to align with what the maintainer of git, and thus the person who decides whether your patch series gets merged or not, wrote just above? In fact, it seems to me that what Junio said matters a great deal...\n>>\n>> So you think Junio knows more about remote-bzr than I do?\n>\n>\n> This is a classical straw man argument.\n\nIt was not a straw man argument, in fact, it's not an argument at all,\nit's a *question*.\n\n>  No, I do not think that. But I do think that Junio knows enough to review your code, and I do think that the point he raised is valid. You disagree with the importance of his point\n\nNo, you don't understand. Junio pointed out correctly that the code\ndidn't \"work\" in the sense that it didn't do anything, but in fact,\nnot doing anything was good, because we don't need that code. That\nsecond part Junio did not see, that is a fact. So, my claim that it\ndidn't matter was based on information Junio did not have, but you\nimplied that because Junio said it mattered, it did.\n\nPlease select to whom does this matter:\na) users of remote-bzr\nb) git developers that run make -C t\nc) git developers that run make -C contrib/remote-helpers\nd) maintainers of remote-bzr\ne) Junio\n\nPresumably, the answer is e), so is that really important? I don't\nthink so, you and Junio, of course, can disagree, but disagreeing is\nnot insulting. And the fact that very very few people will be affected\nnegatively if the code is merged is a *fact*, not my opinion.\n\n>> I repeat; it\n>> doesn't affect the tests, it doesn't affect the code, it doesn't cause\n>> any problem. remote-bzr could be merged today, in fact, it could have\n>> been merged a month ago.\n>>\n>> You don't trust me? Here, look:\n>>\n> [..]\n>\n>> All this code is a no-op, because, as Junio pointed out, cmd is null.\n>> How is that a problem? It's not.\n>\n> It is a problem. Because either the code inside the if is important, and then this is a bug. Or it is not important -- then it should not be there in the first place.\n\nEverything is a problem. You can say that the fact that bazaar exists\nat all is a problem, and ideally bazaar should disappear, and the\nwhole remote-bzr gone. The there are problems, and there are\n*problems*.\n\nI ask you again, who will be affected negatively by this \"problem\"?\n\n> Either way, the patch series should be re-rolled.\n\nNo. A re-roll is one of the many solutions. Another solution is to\nmerge first, fix with a separate patch later.\n\nIn fact, it was Junio himself that proposed to do later fixes of\nremote-bzr on top of what was already merged (v2). Shock horror! This\n\"broken\" code was already merged in 'next', and guess what, nothing\nexploded, because, as I said; it's not broken, it's not a big\n\"problem\".\n\nhttp://article.gmane.org/gmane.comp.version-control.git/210677\n\n> Of course in a whatever time frame suits you. If you are not willing to do that, this is sad, but of course also your right!\n\nAgain, as I said multiple times now, I will fix it, eventually.\n\n> [...]\n>\n>>> This is a very strange attitude...\n>>>\n>>> In another email, you complained about nobody reviewing your patches respectively nobody voicing any constructive criticism. Yet Junio did just that, and again in $gmane/210745 -- and you replied to neither, and acted on neither (not even by refuting the points brought up), and now summarily dismiss them as irrelevant. I find that quite disturbing :-(.\n>>\n>> I didn't say it was irrelevant, it should be fixed,\n>\n> Actually, you wrote:\n>\n>  \"That doesn't matter.\"\n>\n> So I paraphrased. In any case, I am glad to hear you finally agree that it should be fixed (which you did *not* say in your initial reply). So the problem we have seems to be that you do not understand how patches typically handled in git.git.\n\nPlease, spare me the condescension, I think I have enough patches\nlanded in git.git.\n\n> Well, based on my observation: If reviews point out things in a patch series that are not optimal or even broken, it is expected that the submitter fixes this locally and resubmits a new version of the series. In some cases, it is possible to make exceptions, e.g. trivial typo fixes can be applied on the fly. But otherwise, you re-roll, you do not get your stuff merged just based on the promise that you'll submit a series of fixes later. Esp. if the fixes are relatively easy.\n\nNo code is ever perfect. And stop saying \"this should be re-rolled\",\nJunio himself already had this code merged and argued that further\nfixes should be *on top*, of what was already there.\n\nI sent v3 on November 11, he made the mistake of picking v2, if he\nhadn't done that, remote-bzr would be on track for 1.8.1, the same if\nI hadn't asked to pick v3 instead and we continued with v2. The no-op\n\"problem\", might or might not have been spotted, and if it did, Junio\nhimself might have written and pushed a fix *on top* of what was\nalready there (not \"re-roll\"). Even if the problem wasn't spotted,\nusers of 1.8.1 wouldn't be affected negatively in any way, and I\nexplained before, *nobody* would have been affected negatively.\nEventually, I might have spotted the issue myself, and sent a patch\n*on top*, which might be picked for 1.8.2, 1.8.1.1, or maybe even\n1.8.1.\n\nInsisting that this is re-rolled, and that *I* do the fix, is\ninsisting on a synthetic problem that just wouldn't be there if Junio\nhadn't made the mistake of picking v2, or if v2 wasn't reverted.\n\n>> but Junio said\n>> \"With minor fixes, this may be ready for 'next'.\" which is no true\n>> IMO, it's ready *now*, it was ready one month ago. For 'next', this\n>> problem doesn't matter.\n>>\n>> The feedback is appreciated, but delaying the merging of this code for\n>> no reason makes little sense to me.\n>\n> And here goes the insult. You say Junio has no reason to delay the merging.\n\nThat is my opinion. Are you saying that having opinions is insulting?\nOr are you saying that voicing my opinion is insulting? Note that I'm\nbeing careful here, and I'm not stating it as a fact, because it's\nnot. I'm not saying that Junio did something that doesn't make sense,\nI said *to me*, it doesn't make much sense. It follows then, that it\nmight make sense to others, it's a matter of opinion, and having\ndifferent opinions is not insulting.\n\n> When you really mean that you don't agree with his reasons.\n\nThat is exactly what I said.\n\n> So you attack his professionalism and integrity by alluding that he has some ulterior motives to delay the patch.\n\nI never said anything like that. This, actually, is a prime example of\nwhat a straw man argument looks like.\n\n> E.g. that he is hates you, is just mean, does it out of stubbornness, etc.\n\nDon't put words on my mouth.\n\n>> Junio, of course, can do whatever he wants. The removal of this no-op code can wait, or it can be done\n>> on top of v3, there's no need for re-roll, and Junio already\n>> complained about the v3 re-roll.\n>>\n>> And I didn't act because I was on vacations, git development is not my\n>> only priority.\n>\n> Of course. Nobody is complaining that you take too long to reply. We are just unhappy in the way you reply when you do reply :-(.\n\nI know. But I'm only stating facts. The code could be merged to 'next'\ntoday, that is a fact. And in fact, it was already merged in 'next'.\n\n>> And even if I had time, I don't see why I should\n>> prioritize this fix, it's not important, the code is ready.\n>\n> Another straw man: Nobody asked you to prioritize the fix, take your time.\n\n> It was you who asked that the series should be applied without any further fixes.\n\nI didn't ask for anything, I said the series *could* be applied\nwithout any further fixes, the fixes can come next.\n\nAnd I repeat, this \"broken\" code was already applied! Hadn't I asked\nJunio to pick v3 of the series instead, the fix would have to come as\na separate patch *on top* of what was already merged.\n\nYou keep assuming that there's only one way to apply the fix, as a\nre-roll, stop doing that.\n\n>>>>> but there may be others.  It is the responsibility of a contributor to keep\n>>>>> track of review comments others give to his or her patches and\n>>>>> reroll them, so I do not recall every minor details, sorry.\n>>>>\n>>>> There is nothing that prevents remote-bzr from being merged.\n>>>\n>>> Well, I think that is up to Junio to decide in the end, though :-). He wrote\n>>\n>> No. He can decide if the code gets merged, but he is not the voice of\n>> truth. Nothing prevents him from merging the code, except himself.\n>> There is no known issue with the code, that is a true fact.\n>\n> Here are a multitude of fallacies hidden, partially explainable by a differing set of axioms, and/or shear arrogance.\n>\n> Let us re-reread what was said: Initially, you claimed that \"There is nothing that prevents remote-bzr from being merged\".\n>\n> Now, it wasn't said in the above, but let me make it explicit: This statement is \"obviously\"[1] wrong. There are parts of the patch series Junio thinks are not up to par, and he made it quite clear that he will not merge it until these things are resolved.\n\nThat is his *choice*, but nothing is preventing him from merging.\n\nYou are not looking at the claim objectively. If I'm on top of a\nskyscraper and say \"there's nothing that prevents me from jumping\ndown, except myself\" that might be true, even if I have no intentions\nof jumping, because, in fact, the reasons for not jumping are mine.\nHowever, the top of the skyscraper might be surrounded by a glass\nwall, in which case, there is something that would prevent me from\njumping, other than myself.\n\nOf course, completely objectively, the claim that Junio can merge it,\ndoesn't say much, merely that he has commit access, that github is not\ndown, and so on. It just says that *physically* Junio is not\nconstrained from merging. But if you take a step further, it means\nthat among the guidelines of what constitutes reasons for merging, or\nnot merging something, this series does in fact fulfill those reasons.\n\nBut ultimately the proof that there was nothing preventing Junio from\nmerging to 'next' is that *HE ALREADY DID IT*:\n\nhttp://git.kernel.org/?p=git/git.git;a=commitdiff;h=ad38af72b334150e6cf1978721c37077ae3c6d7f\n\nSee? Now tell me that my claim is wrong, and he could in fact not do\nit, if the already did.\n\n> Hence, ignoring all else, there obviously *is* something that prevents remote-bzr from being merged. That is a \"fact\". You even admit so yourself, also contradicting yourself:\n>\n>   \"Nothing prevents him from merging the code, except himself.\"\n>\n>\n> So how is it possible that you can claim that there is nothing that prevents the merge? Ignoring the self-contradicting aspects of what you wrote, the basis for your differing conclusion seems to be that you change the terms of discussion and are using a different set of axioms. In particular, you apparently redefine\n>   \"things that prevent remote-bzr from being merged\"\n> as\n>   \"things that in Felipe's view prevent remote-bzr from being merged\".\n\nNo. No. No. No.\n\nIt's not me that makes something mergeable or not. It's not me who\ndetermines if there's something that prevents a person from jumping\nfrom a skyscraper. Either there are walls, or there are not.\n\nAnd I don't think you know what an axiom means.\n\nEither way, even if my claim was wrong (it isn't, because Junio\nalready did it in the past), it wouldn't be a fallacy.\n\n> Of course one can arbitrarily bend the rules by this definition. For example, we could redefine \"nothing prevents the merge\" as\n>  \"no technical reasons prevent the merge\", and the latter is indeed quite true; your patch series applies perfectly fine, git can do that. Of course the same holds for a patch which removes git.c from the repository, so I don't think this definition is particularly useful...\n\nYou go to great extents to say that my claim is wrong, and then you\nsay: except if... Sorry, that's not logic works.\n\n> This is something what a lot of people would consider a strong insult towards the professionalism and integrity of Junio. There are more examples of this in previous communications between you and other people in the list.\n\nSo you do think disagreeing is insulting. Good to know. I disagree.\n\n> You finally add \"There is no known issue with the code, that is a true fact.\". Within your axiom set, this is certainly true. It certainly is not true in mine or Junio's... Yet you very strongly emphasis with your statement that your set of axioms is the correct one to use here, although I would guess that most people would disagree.\n\nNow it's obvious that you don't know what axiom means:\n\n\"An axiom is a premise or starting point of reasoning. As classically\nconceived, an axiom is a premise so evident as to be accepted as true\nwithout controversy.\"\n\nIf there's controversy, it's not an axiom, because if you change\naxioms, you can argue *anything*.\n\nNo, it is a fact even with commonly shared axioms. Tell me, what\noutstanding issues with this series are going to affect negatively\nanybody? That is the only way you can dispute my claim, by providing\nactual, real, objective issues.\n\n> This is especially arrogant in view of the another straw man argument you are employing: By writing \"[Junio] he is not the voice of truth.\", you implicate that I or anybody were of this opinion.\n\nI did not imply that. If it's not clear, objective issues either\nexist, or they don't. If there are no objective issues, Junio's\nthoughts can't make them appear.\n\n> But I am not, and what I wrote cannot logically be construed as saying so. At least not within what most people would consider as axiom set; of course if your axiom set includes \"Max believes Junio is the voice of truth\", your claim because truth, albeit a tautological one. But let me make clear that any such axioms, or set of axioms leading to that implicating, are inconsistent: In my view, of course Junio is fallible and makes mistakes, and can be wrong etc. -- like any human being. Including most definitely me and you.\n\nAgain with the shady definition of axioms. The truth is the truth, it\ndoesn't matter what you, Junio, or I, say; the truth remains the same.\nAxioms are things that can't possibly be wrong, not what anybody\nconsiders is the truth.\n\nAnd even if you were correct in all that, you haven't provided a\nsingle possible fallacy. Here is a list:\nhttp://en.wikipedia.org/wiki/List_of_fallacies\n\nI haven't seen you arguing that I committed any of those.\n\n> This is a horrible way of working within a team effort :-(. I find this a great pity, because I believe you are doing some really nice work, I esp. like your remote-hg which works much better for me than the others I tried so far.\n\nI'm not going to voice my opinion on this, because to you, apparently\nvoicing my opinion is insulting.\n\n> [1]  As a mathematician, I was taught to avoid the word \"obvious\" in any written form of proof, as it makes you sound arrogant, and it also discourages the reader from thinking critical about a statement, which is considered extremely bad. But since you like it so much, I am using here on purpose.\n\nWe are not writing mathematical proofs, and even if we were, avoiding\nthe word \"obvious\" would be a guideline, right? Your paper wouldn't be\nrejected if you did use it.\n\n\nI'm going to say it one last time; merging this patch series either\ncreates issues for the users, or not. There is a reality out there,\nindependent of what you, Junio, or me think or say. And the fact is,\nthat if this patch series is going to create issues for the users,\n*nobody* has pointed out why, so, since there's no evidence for it,\nthe only rational thing to do is believe that there will be no issues\nfor the users.\n\nThere is no known issue with the code, that is a fact. This code could\nbe easily merged today, and in fact, it was merged by Junio already\n(but then reverted). There are no positive outcomes from the delay,\nonly negative ones. I will address the minute issue about the extra\ncruft, eventually.\n\nI'm not going to reply to this thread any more, because when you have\nto explain in a discussion what 'axiom' means, you know the points of\nview could hardly be more distant, and it would take a lifetime to\nconverge. Same for what a fallacy is, what an argument is, and what\nstraw man means.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204896","messageId":"50CC2244.4040103@alum.mit.edu","threadId":"32327","inReplyTo":"CAMP44s0r_KAKt7Lm1cdumN1cOWzjab3ruYqxp-s6OR1g1qqbcQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-12-15T07:09:56Z","receivedAt":"2012-12-15T07:09:56Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 12/15/2012 04:14 AM, Felipe Contreras wrote:\n> I'm going to say it one last time; merging this patch series either\n> creates issues for the users, or not. There is a reality out there,\n> independent of what you, Junio, or me think or say. And the fact is,\n> that if this patch series is going to create issues for the users,\n> *nobody* has pointed out why, so, since there's no evidence for it,\n> the only rational thing to do is believe that there will be no issues\n> for the users.\n> \n> There is no known issue with the code, that is a fact. This code could\n> be easily merged today, and in fact, it was merged by Junio already\n> (but then reverted). There are no positive outcomes from the delay,\n> only negative ones. I will address the minute issue about the extra\n> cruft, eventually.\n\nCruft in the codebase is a problem for git *developers* because it makes\nthe code harder to maintain and extend.\n\nAnd therefore cruft is a problem for git *users* because it slows down\nfuture development (in whatever small amount).\n\nMoreover, it is dangerous for a project to accept crufty code based on a\ncontributor's promise to clean up the code later:\n\n* The developer might not get around to it, or might take longer than\nexpected.\n\n* Until it is cleaned up, the cruft hinders other potential developers\nto that code.\n\n* The presence of cruft lowers the expectation of quality for the whole\nproject; cruft breeds more cruft.\n\nIt is simpler and fairer to have a policy \"no crufty code\" than to try\nto evaluate each instance on a case-by-case basis.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"204897","messageId":"CAMP44s0=R3rdnD-Zpzz_7wY6HKKsAL1sPVYh4pc3z1CBbX2ODg@mail.gmail.com","threadId":"32327","inReplyTo":"50CC2244.4040103@alum.mit.edu","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-15T07:45:44Z","receivedAt":"2012-12-15T07:45:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Dec 15, 2012 at 1:09 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 12/15/2012 04:14 AM, Felipe Contreras wrote:\n>> I'm going to say it one last time; merging this patch series either\n>> creates issues for the users, or not. There is a reality out there,\n>> independent of what you, Junio, or me think or say. And the fact is,\n>> that if this patch series is going to create issues for the users,\n>> *nobody* has pointed out why, so, since there's no evidence for it,\n>> the only rational thing to do is believe that there will be no issues\n>> for the users.\n>>\n>> There is no known issue with the code, that is a fact. This code could\n>> be easily merged today, and in fact, it was merged by Junio already\n>> (but then reverted). There are no positive outcomes from the delay,\n>> only negative ones. I will address the minute issue about the extra\n>> cruft, eventually.\n\nCouple of facts first:\na) This code was already merged\nb) This code is for a test\nc) I'm the only developer so far\n\n> Cruft in the codebase is a problem for git *developers* because it makes\n> the code harder to maintain and extend.\n\nA problem big enough to warrant the rejection of the patch series? No.\n\n> And therefore cruft is a problem for git *users* because it slows down\n> future development (in whatever small amount).\n\nDon't confuse potential issues with real ones. It *might* slow down\nfuture development, but will it do it with absolute certainty and\nbeyond any reasonable doubt? No, it might not slow anything at all.\n\nAnd even if it does, by how much? 50%? 10%? 1%? Chances are it would\nbe barely noticeable to the users.\n\nAnd even if it was substantial, this is on *test* code. Most users\nsurvive just fine with most of the contrib code not having tests at\nall, they can probably survive with the development of the test code\nfor remote-bzr being a tad slower.\n\nBut who are these developers that would be slowed down? So far I'm the\nonly contributor, and I'm not going to be slowed. If and when somebody\nelse contributes, and find his or her development is slowed down by\nthis, he or her would probably start by removing that code his or\nherself, and submit the appropriate patch.\n\n> Moreover, it is dangerous for a project to accept crufty code based on a\n> contributor's promise to clean up the code later:\n\nBut it was already accepted:\nhttp://git.kernel.org/?p=git/git.git;a=commitdiff;h=ad38af72b334150e6cf1978721c37077ae3c6d7f\n\nThe world didn't end the first time, presumably, if this code is\naccepted again, the world will not end either.\n\n> * The developer might not get around to it, or might take longer than\n> expected.\n\nSomebody else could do it. This is collaborative development after\nall, is it not?\n\nI don't see people halting because something is somebody else's code.\n\n> * Until it is cleaned up, the cruft hinders other potential developers\n> to that code.\n\nHow many *potential* developers are we talking about? By how much?\n\n> * The presence of cruft lowers the expectation of quality for the whole\n> project; cruft breeds more cruft.\n\nPlease. This is in test code for the contrib area, most code in that\narea doesn't even have tests.\n\n> It is simpler and fairer to have a policy \"no crufty code\" than to try\n> to evaluate each instance on a case-by-case basis.\n\nEven then, the problem can be easily solved by simply removing the\nwhole file (contrib/remote-helpers/test-bzr.sh), I say that has more\npotential to hurt users and developers, but hey, \"no crufty code\".\nSince most code in the contrib area doesn't have tests, we would still\nbe following the \"policy\".\n\nNone of this benefits the *real* users one iota.\n\nAnyway, these theoretical minute problems aren't worth worrying about,\nnor discussing. If you want to damage real users, go ahead.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204900","messageId":"CACsJy8A=-3-C29LKQasfUih24cSZrRuQRJ28WjP0zKg=NaFuUA@mail.gmail.com","threadId":"32327","inReplyTo":"CAMP44s0=R3rdnD-Zpzz_7wY6HKKsAL1sPVYh4pc3z1CBbX2ODg@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-12-15T08:44:37Z","receivedAt":"2012-12-15T08:44:37Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> Couple of facts first:\n> a) This code was already merged\n> b) This code is for a test\n> c) I'm the only developer so far\n>\n>> Cruft in the codebase is a problem for git *developers* because it makes\n>> the code harder to maintain and extend.\n>\n> A problem big enough to warrant the rejection of the patch series? No.\n\nMay I suggest you maintain remote-bzr as a separate project? You have\ntotal control that way without anyone's disagreeing with you. So you\nmay be more productive and we have less of these emails back and\nforth. And speaking from someone whose series may take months to get\nin, why the rush?\n-- \nDuy\n"},{"id":"204901","messageId":"CAMP44s0ou-8u1N7k8U9qHfagFJR4Jn6HYWZ8_jWgXgRUuzUJEQ@mail.gmail.com","threadId":"32327","inReplyTo":"CACsJy8A=-3-C29LKQasfUih24cSZrRuQRJ28WjP0zKg=NaFuUA@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-15T09:24:35Z","receivedAt":"2012-12-15T09:24:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Dec 15, 2012 at 2:44 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n\n>>> Cruft in the codebase is a problem for git *developers* because it makes\n>>> the code harder to maintain and extend.\n>>\n>> A problem big enough to warrant the rejection of the patch series? No.\n>\n> May I suggest you maintain remote-bzr as a separate project? You have\n> total control that way without anyone's disagreeing with you.\n\nWhich disagreement? We have all agreed how the code should look like\nin the end. The disagreement is on how and when this code should be\nmerged to git.git. A separate project is not going to help there.\n\n> And speaking from someone whose series may take months to get\n> in, why the rush?\n\nWhy the delay? Junio had already merged this code to 'next'.\n\n-- \nFelipe Contreras\n"}]}