* What's cooking in git.git (Dec 2012, #03; Wed, 12) @ 2012-12-12 23:58 Junio C Hamano 2012-12-13 6:08 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2012-12-12 23:58 UTC (permalink / raw) To: git Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. A new maintenance release 1.8.0.2 was tagged with accumulated fixes we have already been using on the 'master' front for a while. The tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are getting into good shape in 'next', hopefully ready to be merged soon after the 1.8.1 final. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -------------------------------------------------- [New Topics] * sp/shortlog-missing-lf (2012-12-11) 2 commits (merged to 'next' on 2012-12-11 at 64b8429) + strbuf_add_wrapped*(): Remove unused return value + shortlog: fix wrapping lines of wraplen When a line to be wrapped has a solid run of non space characters whose length exactly is the wrap width, "git shortlog -w" failed to add a newline after such a line. Will cook in 'next'. * ap/log-mailmap (2012-12-11) 6 commits - [DO NOT MERGE] seems to break t4013 & t4014 among other things - log: Add --use-mailmap option - pretty: Use mailmap to display username and email - mailmap: Add mailmap structure to rev_info and pp - mailmap: Remove buffer length limit in map_user - Use split_ident_line to parse author and committer Clean up various codepaths around mailmap and teach the "log" machinery to use it. * jc/fetch-ignore-symref (2012-12-11) 1 commit - fetch: ignore wildcarded refspecs that update local symbolic refs Avoid false error from an attempt to update local symbolic ref via fetch. * md/gitweb-sort-by-age (2012-12-11) 1 commit - gitweb: Sort projects with undefined ages last Will merge to 'next'. * ss/nedmalloc-compilation (2012-12-11) 1 commit - nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2 Will merge to 'next'. * wk/submodule-update-remote (2012-12-12) 3 commits - submodule add: If --branch is given, record it in .gitmodules - submodule update: add --remote for submodule's upstream changes - submodule: add get_submodule_config helper funtion Expecting a re-roll. -------------------------------------------------- [Graduated to "master"] * ef/mingw-rmdir (2012-12-10) 1 commit + mingw_rmdir: do not prompt for retry when non-empty MinGW has a workaround when rmdir unnecessarily fails to retry with a prompt, but the logic was kicking in when the rmdir failed with ENOTEMPTY, i.e. was expected to fail and there is no point retrying. * ef/mingw-tty-getpass (2012-12-04) 6 commits (merged to 'next' on 2012-12-07 at 1737ff1) + mingw: get rid of getpass implementation + mingw: reuse tty-version of git_terminal_prompt + compat/terminal: separate input and output handles + compat/terminal: factor out echo-disabling + mingw: make fgetc raise SIGINT if apropriate + mingw: correct exit-code for SIGALRM's SIG_DFL Update getpass() emulation for MinGW. * jc/prompt-command-doc (2012-12-11) 1 commit - git-prompt.sh: update PROMPT_COMMAND documentation Recently graduated git-prompt topic to use PROMPT_COMMAND was confusingly documented. With a quick review, it may be a good idea to fast-track this to the 'master branch. -------------------------------------------------- [Stalled] * fc/remote-bzr (2012-11-28) 10 commits - (fixup) test-bzr.sh: fix multi-line string assignment - remote-bzr: detect local repositories - remote-bzr: add support for older versions of bzr - remote-bzr: add support to push special modes - remote-bzr: add support for fecthing special modes - remote-bzr: add simple tests - remote-bzr: update working tree - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - Add new remote-bzr transport helper New remote helper for bzr (v3). With minor fixes, this may be ready for 'next'. * mo/cvs-server-updates (2012-12-09) 18 commits - t9402: Use TABs for indentation - t9402: Rename check.cvsCount and check.list - t9402: Simplify git ls-tree - t9402: Add missing &&; Code style - t9402: No space after IO-redirection - t9402: Dont use test_must_fail cvs - t9402: improve check_end_tree() and check_end_full_tree() - t9402: sed -i is not portable - cvsserver Documentation: new cvs ... -r support - cvsserver: add t9402 to test branch and tag refs - cvsserver: support -r and sticky tags for most operations - cvsserver: Add version awareness to argsfromdir - cvsserver: generalize getmeta() to recognize commit refs - cvsserver: implement req_Sticky and related utilities - cvsserver: add misc commit lookup, file meta data, and file listing functions - cvsserver: define a tag name character escape mechanism - cvsserver: cleanup extra slashes in filename arguments - cvsserver: factor out git-log parsing logic Needs review by folks interested in cvsserver. * as/check-ignore (2012-11-08) 14 commits - t0007: fix tests on Windows - Documentation/check-ignore: we show the deciding match, not the first - Add git-check-ignore sub-command - dir.c: provide free_directory() for reclaiming dir_struct memory - pathspec.c: move reusable code from builtin/add.c - dir.c: refactor treat_gitlinks() - dir.c: keep track of where patterns came from - dir.c: refactor is_path_excluded() - dir.c: refactor is_excluded() - dir.c: refactor is_excluded_from_list() - dir.c: rename excluded() to is_excluded() - dir.c: rename excluded_from_list() to is_excluded_from_list() - dir.c: rename path_excluded() to is_path_excluded() - dir.c: rename cryptic 'which' variable to more consistent name Duy helped to reroll this. Expecting a re-roll. * aw/rebase-am-failure-detection (2012-10-11) 1 commit - rebase: Handle cases where format-patch fails I am unhappy a bit about the possible performance implications of having to store the output in a temporary file only for a rare case of format-patch aborting. * jk/lua-hackery (2012-10-07) 6 commits - pretty: fix up one-off format_commit_message calls - Minimum compilation fixup - Makefile: make "lua" a bit more configurable - add a "lua" pretty format - add basic lua infrastructure - pretty: make some commit-parsing helpers more public Interesting exercise. When we do this for real, we probably would want to wrap a commit to make it more like an "object" with methods like "parents", etc. * fc/remote-testgit-feature-done (2012-10-29) 1 commit - remote-testgit: properly check for errors Needs review and Ack (or Nack) from people involved in the remote helper interface for this to move forward. * rc/maint-complete-git-p4 (2012-09-24) 1 commit (merged to 'next' on 2012-10-29 at af52cef) + Teach git-completion about git p4 Comment from Pete will need to be addressed in a follow-up patch. * as/test-tweaks (2012-09-20) 7 commits - tests: paint unexpectedly fixed known breakages in bold red - tests: test the test framework more thoroughly - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up - tests: refactor mechanics of testing in a sub test-lib - tests: paint skipped tests in bold blue - tests: test number comes first in 'not ok $count - $message' - tests: paint known breakages in bold yellow Various minor tweaks to the test framework to paint its output lines in colors that match what they mean better. Has the "is this really blue?" issue Peff raised resolved??? * jc/maint-name-rev (2012-09-17) 7 commits - describe --contains: use "name-rev --algorithm=weight" - name-rev --algorithm=weight: tests and documentation - name-rev --algorithm=weight: cache the computed weight in notes - name-rev --algorithm=weight: trivial optimization - name-rev: --algorithm option - name_rev: clarify the logic to assign a new tip-name to a commit - name-rev: lose unnecessary typedef "git name-rev" names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the "describe --contains" even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Stalled mostly due to lack of responses. * jc/xprm-generation (2012-09-14) 1 commit - test-generation: compute generation numbers and clock skews A toy to analyze how bad the clock skews are in histories of real world projects. Stalled mostly due to lack of responses. * jc/blame-no-follow (2012-09-21) 2 commits - blame: pay attention to --no-follow - diff: accept --no-follow option Teaches "--no-follow" option to "git blame" to disable its whole-file rename detection. Stalled mostly due to lack of responses. * jc/doc-default-format (2012-11-26) 2 commits - [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..." - Allow generating a non-default set of documentation Need to address the installation half if this is to be any useful. * mk/maint-graph-infinity-loop (2012-09-25) 1 commit - graph.c: infinite loop in git whatchanged --graph -m The --graph code fell into infinite loop when asked to do what the code did not expect ;-) Anybody who worked on "--graph" wants to comment? Stalled mostly due to lack of responses. * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default "git add dir/" updated modified files and added new files, but does not notice removed files, which may be "Huh?" to some users. They can of course use "git add -A dir/", but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer term. Waiting for comments. * mb/remote-default-nn-origin (2012-07-11) 6 commits - Teach get_default_remote to respect remote.default. - Test that plain "git fetch" uses remote.default when on a detached HEAD. - Teach clone to set remote.default. - Teach "git remote" about remote.default. - Teach remote.c about the remote.default configuration setting. - Rename remote.c's default_remote_name static variables. When the user does not specify what remote to interact with, we often attempt to use 'origin'. This can now be customized via a configuration variable. Expecting a re-roll. "The first remote becomes the default" bit is better done as a separate step. -------------------------------------------------- [Cooking] * jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit (merged to 'next' on 2012-12-11 at 6659fdc) + sh-setup: work around "unset IFS" bug in some shells Will cook in 'next'. * jc/merge-blobs (2012-12-09) 4 commits - merge-tree: add comments to clarify what these functions are doing - merge-tree: lose unused "resolve_directories" - merge-tree: lose unused "flags" from merge_list - Which merge_file() function do you mean? A beginning of a new merge strategy based on the disused merge-tree proof-of-concept code. * jc/same-encoding (2012-12-10) 1 commit - format_commit_message(): simplify calls to logmsg_reencode() Finishing touches to the series to unify "Do we need to reencode between these two encodings?" logic. * nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit - cache-tree: invalidate i-t-a paths after generating trees Writing out a tree object when you still have intent-to-add entries in the index left an incorrect cache-tree data there. * jl/submodule-deinit (2012-12-04) 1 commit (merged to 'next' on 2012-12-07 at ea772f0) + submodule: add 'deinit' command There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "submodule init". "submodule deinit" is the way to do so. Will cook in 'next'. * sl/git-svn-docs (2012-12-05) 4 commits (merged to 'next' on 2012-12-07 at 5bfbb73) + git-svn: Note about tags. + git-svn: Expand documentation for --follow-parent + git-svn: Recommend use of structure options. + git-svn: Document branches with at-sign(@). Will cook in 'next'. * pf/editor-ignore-sigint (2012-12-02) 5 commits (merged to 'next' on 2012-12-07 at 6b04419) + launch_editor: propagate signals from editor to git + run-command: do not warn about child death from terminal + launch_editor: ignore terminal signals while editor has control + launch_editor: refactor to use start/finish_command + run-command: drop silent_exec_failure arg from wait_or_whine Avoid confusing cases where the user hits Ctrl-C while in the editor session, not realizing git will receive the signal. Since most editors will take over the terminal and will block SIGINT, this is not likely to confuse anyone. Will cook in 'next'. * bc/append-signed-off-by (2012-11-26) 11 commits - Unify appending signoff in format-patch, commit and sequencer - format-patch: update append_signoff prototype - format-patch: stricter S-o-b detection - t4014: more tests about appending s-o-b lines - sequencer.c: teach append_signoff to avoid adding a duplicate newline - sequencer.c: teach append_signoff how to detect duplicate s-o-b - sequencer.c: always separate "(cherry picked from" from commit body - sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer - t/t3511: add some tests of 'cherry-pick -s' functionality - t/test-lib-functions.sh: allow to specify the tag name to test_commit - sequencer.c: remove broken support for rfc2822 continuation in footer Expecting a re-roll after a review. * mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits (merged to 'next' on 2012-12-03 at d677090) + wrap_in_html(): process message in bulk rather than line-by-line + wrap_in_html(): use strbuf_addstr_xml_quoted() + imap-send: change msg_data from storing (ptr, len) to storing strbuf + imap-send: correctly report errors reading from stdin + imap-send: store all_msgs as a strbuf + lf_to_crlf(): NUL-terminate msg_data::data + xml_entities(): use function strbuf_addstr_xml_quoted() + Add new function strbuf_add_xml_quoted() Update imap-send to reuse xml quoting code from http-push codepath, clean up some code, and fix a small bug. Will cook in 'next'. * jc/doc-maintainer (2012-11-27) 1 commit - update "howto maintain git" An early draft that is still incomplete. * jk/fsck-dot-in-trees (2012-11-28) 2 commits (merged to 'next' on 2012-11-28 at 519dabc) + fsck: warn about ".git" in trees + fsck: warn about '.' and '..' in trees Will cook in 'next'. * mh/doc-remote-helpers (2012-12-07) 6 commits (merged to 'next' on 2012-12-07 at 7ac8c25) + git-remote-helpers.txt: clarify options & ref list attributes + git-remote-helpers.txt: clarify command <-> capability correspondences + git-remote-helpers.txt: rearrange description of capabilities + git-remote-helpers.txt: minor grammar fix + git-remote-helpers.txt: document missing capabilities + git-remote-helpers.txt: document invocation before input format Will merge to 'master'. * mh/pthreads-autoconf (2012-11-27) 1 commit (merged to 'next' on 2012-11-28 at 780600e) + configure.ac: fix pthreads detection on Mac OS X Will cook in 'next'. * jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits (merged to 'next' on 2012-11-28 at 43d51c2) + config: exit on error accessing any config file + doc: advertise GIT_CONFIG_NOSYSTEM + config: treat user and xdg config permission problems as errors + config, gitignore: failure to access with ENOTDIR is ok An RFC to deal with a situation where .config/git is a file and we notice .config/git/config is not readable due to ENOTDIR, not ENOENT. Will cook in 'next'. * mh/ceiling (2012-10-29) 8 commits (merged to 'next' on 2012-11-26 at d1ce76a) + string_list_longest_prefix(): remove function + setup_git_directory_gently_1(): resolve symlinks in ceiling paths + longest_ancestor_length(): require prefix list entries to be normalized + longest_ancestor_length(): take a string_list argument for prefixes + longest_ancestor_length(): use string_list_split() + Introduce new function real_path_if_valid() + real_path_internal(): add comment explaining use of cwd + Introduce new static function real_path_internal() Elements of GIT_CEILING_DIRECTORIES list may not match the real pathname we obtain from getcwd(), leading the GIT_DIR discovery logic to escape the ceilings the user thought to have specified. Resurrected from Stalled; the earlier performance fear was unwarranted. Will cook in 'next'. * fc/fast-export-fixes (2012-12-03) 15 commits (merged to 'next' on 2012-12-03 at f9df523) + fast-export: make sure updated refs get updated + fast-export: don't handle uninteresting refs + fast-export: fix comparison in tests + fast-export: trivial cleanup + remote-testgit: implement the "done" feature manually + remote-testgit: report success after an import + remote-testgit: exercise more features + remote-testgit: cleanup tests + remote-testgit: remove irrelevant test + remote-testgit: remove non-local functionality + Add new simplified git-remote-testgit + Rename git-remote-testgit to git-remote-testpy + remote-helpers: fix failure message + remote-testgit: fix direction of marks + fast-export: avoid importing blob marks Will cook in 'next'. * jc/apply-trailing-blank-removal (2012-10-12) 1 commit (merged to 'next' on 2012-11-26 at 3af69e7) + apply.c:update_pre_post_images(): the preimage can be truncated Fix to update_pre_post_images() that did not take into account the possibility that whitespace fix could shrink the preimage and change the number of lines in it. Will cook in 'next'. * nd/pathspec-wildcard (2012-11-26) 4 commits (merged to 'next' on 2012-12-03 at eca0fcb) + tree_entry_interesting: do basedir compare on wildcard patterns when possible + pathspec: apply "*.c" optimization from exclude + pathspec: do exact comparison on the leading non-wildcard part + pathspec: save the non-wildcard length part Will cook in 'next'. * nd/wildmatch (2012-11-20) 14 commits (merged to 'next' on 2012-11-21 at 151288f) + test-wildmatch: avoid Windows path mangling (merged to 'next' on 2012-10-25 at 510e8df) + Support "**" wildcard in .gitignore and .gitattributes + wildmatch: make /**/ match zero or more directories + wildmatch: adjust "**" behavior + wildmatch: fix case-insensitive matching + wildmatch: remove static variable force_lower_case + wildmatch: make wildmatch's return value compatible with fnmatch + t3070: disable unreliable fnmatch tests + Integrate wildmatch to git + wildmatch: follow Git's coding convention + wildmatch: remove unnecessary functions + Import wildmatch from rsync + ctype: support iscntrl, ispunct, isxdigit and isprint + ctype: make sane_ctype[] const array Allows pathname patterns in .gitignore and .gitattributes files with double-asterisks "foo/**/bar" to match any number of directory hierarchies. I suspect that this needs to be plugged to pathspec matching code; otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for commits that touch Documentation/git.txt, which would be confusing to the users. Will cook in 'next'. * cr/push-force-tag-update (2012-12-03) 10 commits (merged to 'next' on 2012-12-04 at af2e3a9) + push: allow already-exists advice to be disabled + push: rename config variable for more general use + push: cleanup push rules comment + push: clarify rejection of update to non-commit-ish + push: require force for annotated tags + push: require force for refs under refs/tags/ + push: flag updates that require force + push: keep track of "update" state separately + push: add advice for rejected tag reference + push: return reject reasons as a bitset Require "-f" for push to update a tag, even if it is a fast-forward. Will cook in 'next'. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-12 23:58 What's cooking in git.git (Dec 2012, #03; Wed, 12) Junio C Hamano @ 2012-12-13 6:08 ` Felipe Contreras 2012-12-13 8:11 ` Junio C Hamano 0 siblings, 1 reply; 16+ messages in thread From: Felipe Contreras @ 2012-12-13 6:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Wed, Dec 12, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote: > [Stalled] > > * fc/remote-bzr (2012-11-28) 10 commits > - (fixup) test-bzr.sh: fix multi-line string assignment > - remote-bzr: detect local repositories > - remote-bzr: add support for older versions of bzr > - remote-bzr: add support to push special modes > - remote-bzr: add support for fecthing special modes > - remote-bzr: add simple tests > - remote-bzr: update working tree > - remote-bzr: add support for remote repositories > - remote-bzr: add support for pushing > - Add new remote-bzr transport helper > > New remote helper for bzr (v3). With minor fixes, this may be ready > for 'next'. What minor fixes? -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 6:08 ` Felipe Contreras @ 2012-12-13 8:11 ` Junio C Hamano 2012-12-13 10:08 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2012-12-13 8:11 UTC (permalink / raw) To: Felipe Contreras; +Cc: git Felipe Contreras <felipe.contreras@gmail.com> writes: > On Wed, Dec 12, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote: > >> [Stalled] >> >> * fc/remote-bzr (2012-11-28) 10 commits >> - (fixup) test-bzr.sh: fix multi-line string assignment >> - remote-bzr: detect local repositories >> - remote-bzr: add support for older versions of bzr >> - remote-bzr: add support to push special modes >> - remote-bzr: add support for fecthing special modes >> - remote-bzr: add simple tests >> - remote-bzr: update working tree >> - remote-bzr: add support for remote repositories >> - remote-bzr: add support for pushing >> - Add new remote-bzr transport helper >> >> New remote helper for bzr (v3). With minor fixes, this may be ready >> for 'next'. > > What minor fixes? Lookng at the above (fixup), $gmane/210744 comes to mind, but there may be others. It is the responsibility of a contributor to keep track of review comments others give to his or her patches and reroll them, so I do not recall every minor details, sorry. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 8:11 ` Junio C Hamano @ 2012-12-13 10:08 ` Felipe Contreras 2012-12-13 12:04 ` Max Horn 2012-12-13 19:31 ` Junio C Hamano 0 siblings, 2 replies; 16+ messages in thread From: Felipe Contreras @ 2012-12-13 10:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: >>> New remote helper for bzr (v3). With minor fixes, this may be ready >>> for 'next'. >> >> What minor fixes? > > Lookng at the above (fixup), $gmane/210744 comes to mind That doesn't matter. The code and the tests would work just fine. > but there may be others. It is the responsibility of a contributor to keep > track of review comments others give to his or her patches and > reroll them, so I do not recall every minor details, sorry. There is nothing that prevents remote-bzr from being merged. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 10:08 ` Felipe Contreras @ 2012-12-13 12:04 ` Max Horn 2012-12-13 19:06 ` Felipe Contreras 2012-12-13 19:31 ` Junio C Hamano 1 sibling, 1 reply; 16+ messages in thread From: Max Horn @ 2012-12-13 12:04 UTC (permalink / raw) To: Felipe Contreras; +Cc: Junio C Hamano, git On 13.12.2012, at 11:08, Felipe Contreras wrote: > On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Felipe Contreras <felipe.contreras@gmail.com> writes: > >>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>> for 'next'. >>> >>> What minor fixes? >> >> Lookng at the above (fixup), $gmane/210744 comes to mind > > That doesn't matter. The code and the tests would work just fine. 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... This is a very strange attitude... 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 :-(. > >> but there may be others. It is the responsibility of a contributor to keep >> track of review comments others give to his or her patches and >> reroll them, so I do not recall every minor details, sorry. > > There is nothing that prevents remote-bzr from being merged. Well, I think that is up to Junio to decide in the end, though :-). He wrote Cheers, Max ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 12:04 ` Max Horn @ 2012-12-13 19:06 ` Felipe Contreras 2012-12-14 13:11 ` Max Horn 0 siblings, 1 reply; 16+ messages in thread From: Felipe Contreras @ 2012-12-13 19:06 UTC (permalink / raw) To: Max Horn; +Cc: Junio C Hamano, git On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote: > > On 13.12.2012, at 11:08, Felipe Contreras wrote: > >> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >>> Felipe Contreras <felipe.contreras@gmail.com> writes: >> >>>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>>> for 'next'. >>>> >>>> What minor fixes? >>> >>> Lookng at the above (fixup), $gmane/210744 comes to mind >> >> That doesn't matter. The code and the tests would work just fine. > > > 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... So you think Junio knows more about remote-bzr than I do? I repeat; it doesn't affect the tests, it doesn't affect the code, it doesn't cause any problem. remote-bzr could be merged today, in fact, it could have been merged a month ago. You don't trust me? Here, look: cmd=<<EOF import bzrlib bzrlib.initialize() import bzrlib.plugin bzrlib.plugin.load_plugins() import bzrlib.plugins.fastimport EOF if ! "$PYTHON_PATH" -c "$cmd"; then echo "consider setting BZR_PLUGIN_PATH=$HOME/.bazaar/plugins" 1>&2 skip_all='skipping remote-bzr tests; bzr-fastimport not available' test_done fi All this code is a no-op, because, as Junio pointed out, cmd is null. How is that a problem? It's not. The first version of remote-bzr relied on the bazaar fastimport plug-in, so this check was needed, in case you had bazaar, but not this particular plug-in, but today remote-bzr doesn't need this plug-in, so this chunk of code should be removed. The fact that this code does nothing (because python -c '' does nothing) is *not a problem*. In fact, even if that code failed 100% of the time, it wouldn't hurt anybody, because 'make -C t' would work, everything would work, the only thing that would fail is 'make -C contrib/remote-helpers/ test-bzr', which very very few people would consider a problem. But it doesn't fail, it works. Who benefits by delaying the merging of this code? Nobody. Who gets hurt? The users, of course. > This is a very strange attitude... > > 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 :-(. I didn't say it was irrelevant, it should be fixed, but Junio said "With minor fixes, this may be ready for 'next'." which is no true IMO, it's ready *now*, it was ready one month ago. For 'next', this problem doesn't matter. The feedback is appreciated, but delaying the merging of this code for no reason makes little sense to me. Junio, of course, can do whatever he wants. The removal of this no-op code can wait, or it can be done on top of v3, there's no need for re-roll, and Junio already complained about the v3 re-roll. And I didn't act because I was on vacations, git development is not my only priority. And even if I had time, I don't see why I should prioritize this fix, it's not important, the code is ready. >>> but there may be others. It is the responsibility of a contributor to keep >>> track of review comments others give to his or her patches and >>> reroll them, so I do not recall every minor details, sorry. >> >> There is nothing that prevents remote-bzr from being merged. > > Well, I think that is up to Junio to decide in the end, though :-). He wrote No. He can decide if the code gets merged, but he is not the voice of truth. Nothing prevents him from merging the code, except himself. There is no known issue with the code, that is a true fact. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 19:06 ` Felipe Contreras @ 2012-12-14 13:11 ` Max Horn 2012-12-15 3:14 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Max Horn @ 2012-12-14 13:11 UTC (permalink / raw) To: Felipe Contreras; +Cc: Junio C Hamano, git Felipe, 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. 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? 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. 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". 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. 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? 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: On 13.12.2012, at 20:06, Felipe Contreras wrote: > On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote: >> >> On 13.12.2012, at 11:08, Felipe Contreras wrote: >> >>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >>>> Felipe Contreras <felipe.contreras@gmail.com> writes: >>> >>>>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>>>> for 'next'. >>>>> >>>>> What minor fixes? >>>> >>>> Lookng at the above (fixup), $gmane/210744 comes to mind >>> >>> That doesn't matter. The code and the tests would work just fine. >> >> >> 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... > > So you think Junio knows more about remote-bzr than I do? This 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 > I repeat; it > doesn't affect the tests, it doesn't affect the code, it doesn't cause > any problem. remote-bzr could be merged today, in fact, it could have > been merged a month ago. > > You don't trust me? Here, look: > [..] > All this code is a no-op, because, as Junio pointed out, cmd is null. > How is that a problem? It's not. 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. Either 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! [...] >> This is a very strange attitude... >> >> 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 :-(. > > I didn't say it was irrelevant, it should be fixed, Actually, you wrote: "That doesn't matter." 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. 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. Of 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. This 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. > but Junio said > "With minor fixes, this may be ready for 'next'." which is no true > IMO, it's ready *now*, it was ready one month ago. For 'next', this > problem doesn't matter. > > The feedback is appreciated, but delaying the merging of this code for > no reason makes little sense to me. And 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. > Junio, of course, can do whatever he wants. The removal of this no-op code can wait, or it can be done > on top of v3, there's no need for re-roll, and Junio already > complained about the v3 re-roll. > > And I didn't act because I was on vacations, git development is not my > only priority. 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 :-(. > And even if I had time, I don't see why I should > prioritize this fix, it's not important, the code is ready. Another 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. > >>>> but there may be others. It is the responsibility of a contributor to keep >>>> track of review comments others give to his or her patches and >>>> reroll them, so I do not recall every minor details, sorry. >>> >>> There is nothing that prevents remote-bzr from being merged. >> >> Well, I think that is up to Junio to decide in the end, though :-). He wrote > > No. He can decide if the code gets merged, but he is not the voice of > truth. Nothing prevents him from merging the code, except himself. > There is no known issue with the code, that is a true fact. Here are a multitude of fallacies hidden, partially explainable by a differing set of axioms, and/or shear arrogance. Let us re-reread what was said: Initially, you claimed that "There is nothing that prevents remote-bzr from being merged". 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. 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: "Nothing prevents him from merging the code, except himself." 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 "things that prevent remote-bzr from being merged" as "things that in Felipe's view prevent remote-bzr from being merged". Of course one can arbitrarily bend the rules by this definition. For example, we could redefine "nothing prevents the merge" as "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... Back 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. 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. 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. 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. 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. 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. Bye, Max [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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-14 13:11 ` Max Horn @ 2012-12-15 3:14 ` Felipe Contreras 2012-12-15 7:09 ` Michael Haggerty 0 siblings, 1 reply; 16+ messages in thread From: Felipe Contreras @ 2012-12-15 3:14 UTC (permalink / raw) To: Max Horn; +Cc: Junio C Hamano, git On Fri, Dec 14, 2012 at 7:11 AM, Max Horn <postbox@quendi.de> wrote: > 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. When I say something is a fact, I do mean it. It's not my opinion, it's not what I think, it's a fact. The Earth revolves around the Sun, Junio is the maintainer, Junio can merge whatever he wants, those are facts. If you think the Earth revolving around the Sun is not a fact, that's your choice, but if you want to convince others that this is not a fact, you need to show *why*. > 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? First of all, it depends on your definition of "broken". To me something broken is something that does not *work*. The code works, the tests have some cruft in it, but it *works*, it's not broken. And I said multiple times now that I WILL FIX IT. I'm not going to repeat it again, and quite frankly, I don't think I'm going to reply to this thread any more. What makes you think that you owe my free time? I do with my free time whatever I want. I will fix it, when I feel like fixing it. This code will not go into 1.8.1, so there's no point hurrying the fix, I have other things to do. > 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. Time is not pressing because Junio decided not to merge, and he decided not to merge, because of this "issue". This hurts users, and benefits no one. > 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". That is what I said. What part of "I didn't say it was irrelevant, it should be fixed" didn't you understand? And no, this is not a "rule", you assume it *must* be re-rolled, it doesn't. > 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. It's not because of me that users would have to wait, it was Junio's decision, there was literally nothing I could do, before, or now, for this code to be merged for 1.8.1. And yes, people can use my repo *if* they know about it, most people just follow the mainline, and many don't even read the news. > 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? Show me *exactly* where I insulted anybody, and show me where I made a false claim. And no, this discussion doesn't delay the acceptance, the acceptance was already delayed before this discussion, there was nothing I could do, neither in the past or present. > 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: Please. > On 13.12.2012, at 20:06, Felipe Contreras wrote: > >> On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <postbox@quendi.de> wrote: >>> >>> On 13.12.2012, at 11:08, Felipe Contreras wrote: >>> >>>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >>>>> Felipe Contreras <felipe.contreras@gmail.com> writes: >>>> >>>>>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>>>>> for 'next'. >>>>>> >>>>>> What minor fixes? >>>>> >>>>> Lookng at the above (fixup), $gmane/210744 comes to mind >>>> >>>> That doesn't matter. The code and the tests would work just fine. >>> >>> >>> 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... >> >> So you think Junio knows more about remote-bzr than I do? > > > This is a classical straw man argument. It was not a straw man argument, in fact, it's not an argument at all, it's a *question*. > 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 No, you don't understand. Junio pointed out correctly that the code didn't "work" in the sense that it didn't do anything, but in fact, not doing anything was good, because we don't need that code. That second part Junio did not see, that is a fact. So, my claim that it didn't matter was based on information Junio did not have, but you implied that because Junio said it mattered, it did. Please select to whom does this matter: a) users of remote-bzr b) git developers that run make -C t c) git developers that run make -C contrib/remote-helpers d) maintainers of remote-bzr e) Junio Presumably, the answer is e), so is that really important? I don't think so, you and Junio, of course, can disagree, but disagreeing is not insulting. And the fact that very very few people will be affected negatively if the code is merged is a *fact*, not my opinion. >> I repeat; it >> doesn't affect the tests, it doesn't affect the code, it doesn't cause >> any problem. remote-bzr could be merged today, in fact, it could have >> been merged a month ago. >> >> You don't trust me? Here, look: >> > [..] > >> All this code is a no-op, because, as Junio pointed out, cmd is null. >> How is that a problem? It's not. > > 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. Everything is a problem. You can say that the fact that bazaar exists at all is a problem, and ideally bazaar should disappear, and the whole remote-bzr gone. The there are problems, and there are *problems*. I ask you again, who will be affected negatively by this "problem"? > Either way, the patch series should be re-rolled. No. A re-roll is one of the many solutions. Another solution is to merge first, fix with a separate patch later. In fact, it was Junio himself that proposed to do later fixes of remote-bzr on top of what was already merged (v2). Shock horror! This "broken" code was already merged in 'next', and guess what, nothing exploded, because, as I said; it's not broken, it's not a big "problem". http://article.gmane.org/gmane.comp.version-control.git/210677 > 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! Again, as I said multiple times now, I will fix it, eventually. > [...] > >>> This is a very strange attitude... >>> >>> 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 :-(. >> >> I didn't say it was irrelevant, it should be fixed, > > Actually, you wrote: > > "That doesn't matter." > > 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. Please, spare me the condescension, I think I have enough patches landed 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. No code is ever perfect. And stop saying "this should be re-rolled", Junio himself already had this code merged and argued that further fixes should be *on top*, of what was already there. I sent v3 on November 11, he made the mistake of picking v2, if he hadn't done that, remote-bzr would be on track for 1.8.1, the same if I hadn't asked to pick v3 instead and we continued with v2. The no-op "problem", might or might not have been spotted, and if it did, Junio himself might have written and pushed a fix *on top* of what was already there (not "re-roll"). Even if the problem wasn't spotted, users of 1.8.1 wouldn't be affected negatively in any way, and I explained before, *nobody* would have been affected negatively. Eventually, I might have spotted the issue myself, and sent a patch *on top*, which might be picked for 1.8.2, 1.8.1.1, or maybe even 1.8.1. Insisting that this is re-rolled, and that *I* do the fix, is insisting on a synthetic problem that just wouldn't be there if Junio hadn't made the mistake of picking v2, or if v2 wasn't reverted. >> but Junio said >> "With minor fixes, this may be ready for 'next'." which is no true >> IMO, it's ready *now*, it was ready one month ago. For 'next', this >> problem doesn't matter. >> >> The feedback is appreciated, but delaying the merging of this code for >> no reason makes little sense to me. > > And here goes the insult. You say Junio has no reason to delay the merging. That is my opinion. Are you saying that having opinions is insulting? Or are you saying that voicing my opinion is insulting? Note that I'm being careful here, and I'm not stating it as a fact, because it's not. I'm not saying that Junio did something that doesn't make sense, I said *to me*, it doesn't make much sense. It follows then, that it might make sense to others, it's a matter of opinion, and having different opinions is not insulting. > When you really mean that you don't agree with his reasons. That is exactly what I said. > So you attack his professionalism and integrity by alluding that he has some ulterior motives to delay the patch. I never said anything like that. This, actually, is a prime example of what a straw man argument looks like. > E.g. that he is hates you, is just mean, does it out of stubbornness, etc. Don't put words on my mouth. >> Junio, of course, can do whatever he wants. The removal of this no-op code can wait, or it can be done >> on top of v3, there's no need for re-roll, and Junio already >> complained about the v3 re-roll. >> >> And I didn't act because I was on vacations, git development is not my >> only priority. > > 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 :-(. I know. But I'm only stating facts. The code could be merged to 'next' today, that is a fact. And in fact, it was already merged in 'next'. >> And even if I had time, I don't see why I should >> prioritize this fix, it's not important, the code is ready. > > Another 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. I didn't ask for anything, I said the series *could* be applied without any further fixes, the fixes can come next. And I repeat, this "broken" code was already applied! Hadn't I asked Junio to pick v3 of the series instead, the fix would have to come as a separate patch *on top* of what was already merged. You keep assuming that there's only one way to apply the fix, as a re-roll, stop doing that. >>>>> but there may be others. It is the responsibility of a contributor to keep >>>>> track of review comments others give to his or her patches and >>>>> reroll them, so I do not recall every minor details, sorry. >>>> >>>> There is nothing that prevents remote-bzr from being merged. >>> >>> Well, I think that is up to Junio to decide in the end, though :-). He wrote >> >> No. He can decide if the code gets merged, but he is not the voice of >> truth. Nothing prevents him from merging the code, except himself. >> There is no known issue with the code, that is a true fact. > > Here are a multitude of fallacies hidden, partially explainable by a differing set of axioms, and/or shear arrogance. > > Let us re-reread what was said: Initially, you claimed that "There is nothing that prevents remote-bzr from being merged". > > 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. That is his *choice*, but nothing is preventing him from merging. You are not looking at the claim objectively. If I'm on top of a skyscraper and say "there's nothing that prevents me from jumping down, except myself" that might be true, even if I have no intentions of jumping, because, in fact, the reasons for not jumping are mine. However, the top of the skyscraper might be surrounded by a glass wall, in which case, there is something that would prevent me from jumping, other than myself. Of course, completely objectively, the claim that Junio can merge it, doesn't say much, merely that he has commit access, that github is not down, and so on. It just says that *physically* Junio is not constrained from merging. But if you take a step further, it means that among the guidelines of what constitutes reasons for merging, or not merging something, this series does in fact fulfill those reasons. But ultimately the proof that there was nothing preventing Junio from merging to 'next' is that *HE ALREADY DID IT*: http://git.kernel.org/?p=git/git.git;a=commitdiff;h=ad38af72b334150e6cf1978721c37077ae3c6d7f See? Now tell me that my claim is wrong, and he could in fact not do it, if the already did. > 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: > > "Nothing prevents him from merging the code, except himself." > > > 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 > "things that prevent remote-bzr from being merged" > as > "things that in Felipe's view prevent remote-bzr from being merged". No. No. No. No. It's not me that makes something mergeable or not. It's not me who determines if there's something that prevents a person from jumping from a skyscraper. Either there are walls, or there are not. And I don't think you know what an axiom means. Either way, even if my claim was wrong (it isn't, because Junio already did it in the past), it wouldn't be a fallacy. > Of course one can arbitrarily bend the rules by this definition. For example, we could redefine "nothing prevents the merge" as > "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... You go to great extents to say that my claim is wrong, and then you say: except if... Sorry, that's not logic works. > 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. So you do think disagreeing is insulting. Good to know. I disagree. > 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. Now it's obvious that you don't know what axiom means: "An axiom is a premise or starting point of reasoning. As classically conceived, an axiom is a premise so evident as to be accepted as true without controversy." If there's controversy, it's not an axiom, because if you change axioms, you can argue *anything*. No, it is a fact even with commonly shared axioms. Tell me, what outstanding issues with this series are going to affect negatively anybody? That is the only way you can dispute my claim, by providing actual, real, objective issues. > 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. I did not imply that. If it's not clear, objective issues either exist, or they don't. If there are no objective issues, Junio's thoughts can't make them appear. > 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. Again with the shady definition of axioms. The truth is the truth, it doesn't matter what you, Junio, or I, say; the truth remains the same. Axioms are things that can't possibly be wrong, not what anybody considers is the truth. And even if you were correct in all that, you haven't provided a single possible fallacy. Here is a list: http://en.wikipedia.org/wiki/List_of_fallacies I haven't seen you arguing that I committed any of those. > 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. I'm not going to voice my opinion on this, because to you, apparently voicing my opinion is insulting. > [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. We are not writing mathematical proofs, and even if we were, avoiding the word "obvious" would be a guideline, right? Your paper wouldn't be rejected if you did use it. I'm going to say it one last time; merging this patch series either creates issues for the users, or not. There is a reality out there, independent of what you, Junio, or me think or say. And the fact is, that if this patch series is going to create issues for the users, *nobody* has pointed out why, so, since there's no evidence for it, the only rational thing to do is believe that there will be no issues for the users. There is no known issue with the code, that is a fact. This code could be easily merged today, and in fact, it was merged by Junio already (but then reverted). There are no positive outcomes from the delay, only negative ones. I will address the minute issue about the extra cruft, eventually. I'm not going to reply to this thread any more, because when you have to explain in a discussion what 'axiom' means, you know the points of view could hardly be more distant, and it would take a lifetime to converge. Same for what a fallacy is, what an argument is, and what straw man means. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-15 3:14 ` Felipe Contreras @ 2012-12-15 7:09 ` Michael Haggerty 2012-12-15 7:45 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Michael Haggerty @ 2012-12-15 7:09 UTC (permalink / raw) To: Felipe Contreras; +Cc: Max Horn, Junio C Hamano, git On 12/15/2012 04:14 AM, Felipe Contreras wrote: > I'm going to say it one last time; merging this patch series either > creates issues for the users, or not. There is a reality out there, > independent of what you, Junio, or me think or say. And the fact is, > that if this patch series is going to create issues for the users, > *nobody* has pointed out why, so, since there's no evidence for it, > the only rational thing to do is believe that there will be no issues > for the users. > > There is no known issue with the code, that is a fact. This code could > be easily merged today, and in fact, it was merged by Junio already > (but then reverted). There are no positive outcomes from the delay, > only negative ones. I will address the minute issue about the extra > cruft, eventually. Cruft in the codebase is a problem for git *developers* because it makes the code harder to maintain and extend. And therefore cruft is a problem for git *users* because it slows down future development (in whatever small amount). Moreover, it is dangerous for a project to accept crufty code based on a contributor's promise to clean up the code later: * The developer might not get around to it, or might take longer than expected. * Until it is cleaned up, the cruft hinders other potential developers to that code. * The presence of cruft lowers the expectation of quality for the whole project; cruft breeds more cruft. It is simpler and fairer to have a policy "no crufty code" than to try to evaluate each instance on a case-by-case basis. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-15 7:09 ` Michael Haggerty @ 2012-12-15 7:45 ` Felipe Contreras 2012-12-15 8:44 ` Nguyen Thai Ngoc Duy 0 siblings, 1 reply; 16+ messages in thread From: Felipe Contreras @ 2012-12-15 7:45 UTC (permalink / raw) To: Michael Haggerty; +Cc: Max Horn, Junio C Hamano, git On Sat, Dec 15, 2012 at 1:09 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote: > On 12/15/2012 04:14 AM, Felipe Contreras wrote: >> I'm going to say it one last time; merging this patch series either >> creates issues for the users, or not. There is a reality out there, >> independent of what you, Junio, or me think or say. And the fact is, >> that if this patch series is going to create issues for the users, >> *nobody* has pointed out why, so, since there's no evidence for it, >> the only rational thing to do is believe that there will be no issues >> for the users. >> >> There is no known issue with the code, that is a fact. This code could >> be easily merged today, and in fact, it was merged by Junio already >> (but then reverted). There are no positive outcomes from the delay, >> only negative ones. I will address the minute issue about the extra >> cruft, eventually. Couple of facts first: a) This code was already merged b) This code is for a test c) I'm the only developer so far > Cruft in the codebase is a problem for git *developers* because it makes > the code harder to maintain and extend. A problem big enough to warrant the rejection of the patch series? No. > And therefore cruft is a problem for git *users* because it slows down > future development (in whatever small amount). Don't confuse potential issues with real ones. It *might* slow down future development, but will it do it with absolute certainty and beyond any reasonable doubt? No, it might not slow anything at all. And even if it does, by how much? 50%? 10%? 1%? Chances are it would be barely noticeable to the users. And even if it was substantial, this is on *test* code. Most users survive just fine with most of the contrib code not having tests at all, they can probably survive with the development of the test code for remote-bzr being a tad slower. But who are these developers that would be slowed down? So far I'm the only contributor, and I'm not going to be slowed. If and when somebody else contributes, and find his or her development is slowed down by this, he or her would probably start by removing that code his or herself, and submit the appropriate patch. > Moreover, it is dangerous for a project to accept crufty code based on a > contributor's promise to clean up the code later: But it was already accepted: http://git.kernel.org/?p=git/git.git;a=commitdiff;h=ad38af72b334150e6cf1978721c37077ae3c6d7f The world didn't end the first time, presumably, if this code is accepted again, the world will not end either. > * The developer might not get around to it, or might take longer than > expected. Somebody else could do it. This is collaborative development after all, is it not? I don't see people halting because something is somebody else's code. > * Until it is cleaned up, the cruft hinders other potential developers > to that code. How many *potential* developers are we talking about? By how much? > * The presence of cruft lowers the expectation of quality for the whole > project; cruft breeds more cruft. Please. This is in test code for the contrib area, most code in that area doesn't even have tests. > It is simpler and fairer to have a policy "no crufty code" than to try > to evaluate each instance on a case-by-case basis. Even then, the problem can be easily solved by simply removing the whole file (contrib/remote-helpers/test-bzr.sh), I say that has more potential to hurt users and developers, but hey, "no crufty code". Since most code in the contrib area doesn't have tests, we would still be following the "policy". None of this benefits the *real* users one iota. Anyway, these theoretical minute problems aren't worth worrying about, nor discussing. If you want to damage real users, go ahead. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-15 7:45 ` Felipe Contreras @ 2012-12-15 8:44 ` Nguyen Thai Ngoc Duy 2012-12-15 9:24 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Nguyen Thai Ngoc Duy @ 2012-12-15 8:44 UTC (permalink / raw) To: Felipe Contreras; +Cc: Michael Haggerty, Max Horn, Junio C Hamano, git On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote: > Couple of facts first: > a) This code was already merged > b) This code is for a test > c) I'm the only developer so far > >> Cruft in the codebase is a problem for git *developers* because it makes >> the code harder to maintain and extend. > > A problem big enough to warrant the rejection of the patch series? No. May I suggest you maintain remote-bzr as a separate project? You have total control that way without anyone's disagreeing with you. So you may be more productive and we have less of these emails back and forth. And speaking from someone whose series may take months to get in, why the rush? -- Duy ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-15 8:44 ` Nguyen Thai Ngoc Duy @ 2012-12-15 9:24 ` Felipe Contreras 0 siblings, 0 replies; 16+ messages in thread From: Felipe Contreras @ 2012-12-15 9:24 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Michael Haggerty, Max Horn, Junio C Hamano, git On Sat, Dec 15, 2012 at 2:44 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote: > On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: >>> Cruft in the codebase is a problem for git *developers* because it makes >>> the code harder to maintain and extend. >> >> A problem big enough to warrant the rejection of the patch series? No. > > May I suggest you maintain remote-bzr as a separate project? You have > total control that way without anyone's disagreeing with you. Which disagreement? We have all agreed how the code should look like in the end. The disagreement is on how and when this code should be merged to git.git. A separate project is not going to help there. > And speaking from someone whose series may take months to get > in, why the rush? Why the delay? Junio had already merged this code to 'next'. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 10:08 ` Felipe Contreras 2012-12-13 12:04 ` Max Horn @ 2012-12-13 19:31 ` Junio C Hamano 2012-12-13 22:05 ` Felipe Contreras 1 sibling, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2012-12-13 19:31 UTC (permalink / raw) To: Felipe Contreras; +Cc: git Felipe Contreras <felipe.contreras@gmail.com> writes: > On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Felipe Contreras <felipe.contreras@gmail.com> writes: > >>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>> for 'next'. >>> >>> What minor fixes? >> >> Lookng at the above (fixup), $gmane/210744 comes to mind > > That doesn't matter. The code and the tests would work just fine. One of us must be very confused. Perhaps you were looking at a wrong message (or I quoted a wrong one?). ... goes and double checks ... One of the review points were about this piece in the test: > +cmd=<<EOF > +import bzrlib > +bzrlib.initialize() > +import bzrlib.plugin > +bzrlib.plugin.load_plugins() > +import bzrlib.plugins.fastimport > +EOF > +if ! "$PYTHON_PATH" -c "$cmd"; then I cannot see how this could have ever worked. And I still don't see how your "would work just fine" can be true. >> but there may be others. It is the responsibility of a contributor to keep >> track of review comments others give to his or her patches and >> reroll them, so I do not recall every minor details, sorry. There may be others, but $gmane/210745 is also relevant, I think. > There is nothing that prevents remote-bzr from being merged. What we merge may not be perfect. Bugs and misdesigns are often identified long after a topic is merged and it is perfectly normal we fix things up in-tree. There are even times where we say "OK, it is known to break if the user does something that pokes this and that obscure corners of this code, but the benefit of merging this 99% working code to help users that do not exercise the rare cases is greater than having them wait for getting the remaining 1% right, so let's merge it with known breakage documentation". But it is totally a different matter to merge a crap with known breakage that is one easy fix away from the get-go. Allowing that means that all the times we spend on reviewing patches here go wasted, discouraging reviewers. If you want others to take your patches with respect, please take reviewers' comments with the same respect you expect to be paid by others. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 19:31 ` Junio C Hamano @ 2012-12-13 22:05 ` Felipe Contreras 2012-12-13 23:42 ` Junio C Hamano 0 siblings, 1 reply; 16+ messages in thread From: Felipe Contreras @ 2012-12-13 22:05 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >>> Felipe Contreras <felipe.contreras@gmail.com> writes: >> >>>>> New remote helper for bzr (v3). With minor fixes, this may be ready >>>>> for 'next'. >>>> >>>> What minor fixes? >>> >>> Lookng at the above (fixup), $gmane/210744 comes to mind >> >> That doesn't matter. The code and the tests would work just fine. > > One of us must be very confused. Perhaps you were looking at a > wrong message (or I quoted a wrong one?). > > ... goes and double checks ... > > One of the review points were about this piece in the test: > > > +cmd=<<EOF > > +import bzrlib > > +bzrlib.initialize() > > +import bzrlib.plugin > > +bzrlib.plugin.load_plugins() > > +import bzrlib.plugins.fastimport > > +EOF > > +if ! "$PYTHON_PATH" -c "$cmd"; then > > I cannot see how this could have ever worked. > > And I still don't see how your "would work just fine" can be true. As I have explained, all this code is the equivalent of python -c '', or rather, it's a no-op. It works in the sense that it doesn't break anything. The purpose of the code is to check for the fastimport plug-in, but that plug-in is not used any more, it's vestigial code, it doesn't matter if the check works or not, as long as it doesn't fail. >>> but there may be others. It is the responsibility of a contributor to keep >>> track of review comments others give to his or her patches and >>> reroll them, so I do not recall every minor details, sorry. > > There may be others, but $gmane/210745 is also relevant, I think. I'll comment on the patch, but I don't think it really prevents the merge. >> There is nothing that prevents remote-bzr from being merged. > > What we merge may not be perfect. Bugs and misdesigns are often > identified long after a topic is merged and it is perfectly normal > we fix things up in-tree. There are even times where we say "OK, it > is known to break if the user does something that pokes this and > that obscure corners of this code, but the benefit of merging this > 99% working code to help users that do not exercise the rare cases > is greater than having them wait for getting the remaining 1% right, > so let's merge it with known breakage documentation". > > But it is totally a different matter to merge a crap with known > breakage that is one easy fix away from the get-go. Allowing that > means that all the times we spend on reviewing patches here go > wasted, discouraging reviewers. There is no breakage. > If you want others to take your patches with respect, please take > reviewers' comments with the same respect you expect to be paid by > others. I don't need others to take my patches with respect, my patches are not people, they don't have feelings. That being said, I don't think I have disrespected any of your comments. Yes, you are right that the above code is wrong and doesn't do anything, what part of agreeing is disrespectful? But I don't agree that it is a merge blocker. Disagreeing is not disrespecting. This code was ready for 1.8.1, but it's not going to be there, so, I don't see any hurry. As I said, I think the code is ready, and these minor details can wait. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 22:05 ` Felipe Contreras @ 2012-12-13 23:42 ` Junio C Hamano 2012-12-14 0:50 ` Felipe Contreras 0 siblings, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2012-12-13 23:42 UTC (permalink / raw) To: Felipe Contreras; +Cc: git Felipe Contreras <felipe.contreras@gmail.com> writes: > On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote: > ... >> One of the review points were about this piece in the test: >> >> > +cmd=<<EOF >> > +import bzrlib >> > +bzrlib.initialize() >> > +import bzrlib.plugin >> > +bzrlib.plugin.load_plugins() >> > +import bzrlib.plugins.fastimport >> > +EOF >> > +if ! "$PYTHON_PATH" -c "$cmd"; then >> >> I cannot see how this could have ever worked. >> >> And I still don't see how your "would work just fine" can be true. > > As I have explained, all this code is the equivalent of python -c '', > or rather, it's a no-op. It works in the sense that it doesn't break > anything. Aren't you ashamed of yourself after having said this? > The purpose of the code is to check for the fastimport plug-in, but > that plug-in is not used any more, it's vestigial code, it doesn't > matter if the check works or not, as long as it doesn't fail. If so, the final version that is suitable for merging would have that unused code stripped away, no? >> But it is totally a different matter to merge a crap with known >> breakage that is one easy fix away from the get-go. Allowing that >> means that all the times we spend on reviewing patches here go >> wasted, discouraging reviewers. > > There is no breakage. Unused code that burdens others to read through to make sure nothing is broken is already broken from maintenance point of view. Why are you wasting my time and everybody's bandwidth on this, when you are very well capable of rerolling the series with removal and style fixes in far shorter time? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What's cooking in git.git (Dec 2012, #03; Wed, 12) 2012-12-13 23:42 ` Junio C Hamano @ 2012-12-14 0:50 ` Felipe Contreras 0 siblings, 0 replies; 16+ messages in thread From: Felipe Contreras @ 2012-12-14 0:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, Dec 13, 2012 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> On Thu, Dec 13, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote: >> ... >>> One of the review points were about this piece in the test: >>> >>> > +cmd=<<EOF >>> > +import bzrlib >>> > +bzrlib.initialize() >>> > +import bzrlib.plugin >>> > +bzrlib.plugin.load_plugins() >>> > +import bzrlib.plugins.fastimport >>> > +EOF >>> > +if ! "$PYTHON_PATH" -c "$cmd"; then >>> >>> I cannot see how this could have ever worked. >>> >>> And I still don't see how your "would work just fine" can be true. >> >> As I have explained, all this code is the equivalent of python -c '', >> or rather, it's a no-op. It works in the sense that it doesn't break >> anything. > > Aren't you ashamed of yourself after having said this? It is a fact. >> The purpose of the code is to check for the fastimport plug-in, but >> that plug-in is not used any more, it's vestigial code, it doesn't >> matter if the check works or not, as long as it doesn't fail. > > If so, the final version that is suitable for merging would have > that unused code stripped away, no? To the users there's absolutely no difference. >>> But it is totally a different matter to merge a crap with known >>> breakage that is one easy fix away from the get-go. Allowing that >>> means that all the times we spend on reviewing patches here go >>> wasted, discouraging reviewers. >> >> There is no breakage. > > Unused code that burdens others to read through to make sure nothing > is broken is already broken from maintenance point of view. Remove the whole test then. I'm already doing way more than most of the code in contrib by providing tests. > Why are you wasting my time and everybody's bandwidth on this, when > you are very well capable of rerolling the series with removal and > style fixes in far shorter time? I will do that, when I do that. We have no time constraints, have we? This code is not getting in 1.8.1 either way. Anyway, if you merge this code as it is, nothing bad will happen. Nobody would get hurt, and in fact, very few, if anybody, would notice. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-12-15 9:25 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-12 23:58 What's cooking in git.git (Dec 2012, #03; Wed, 12) Junio C Hamano 2012-12-13 6:08 ` Felipe Contreras 2012-12-13 8:11 ` Junio C Hamano 2012-12-13 10:08 ` Felipe Contreras 2012-12-13 12:04 ` Max Horn 2012-12-13 19:06 ` Felipe Contreras 2012-12-14 13:11 ` Max Horn 2012-12-15 3:14 ` Felipe Contreras 2012-12-15 7:09 ` Michael Haggerty 2012-12-15 7:45 ` Felipe Contreras 2012-12-15 8:44 ` Nguyen Thai Ngoc Duy 2012-12-15 9:24 ` Felipe Contreras 2012-12-13 19:31 ` Junio C Hamano 2012-12-13 22:05 ` Felipe Contreras 2012-12-13 23:42 ` Junio C Hamano 2012-12-14 0:50 ` Felipe Contreras
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).