What's cooking in git.git (Dec 2012, #03; Wed, 12)

What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Junio C Hamano]

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'.

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Max Horn]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Junio C Hamano]

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?

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Max Horn]

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.

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Michael Haggerty]

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/

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Nguyen Thai Ngoc Duy]

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

Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

[Felipe Contreras]

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