{"thread":{"id":"35130","subject":"My patches","startedAt":"2013-10-12T07:24:50Z","lastAt":"2013-10-18T16:59:41Z","messageCount":12,"participants":["Felipe Contreras","Philip Oakley","Junio C Hamano","Max Horn","Theodore Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"228871","messageId":"20131012072450.GA21165@nysa","threadId":"35130","inReplyTo":null,"subject":"My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-12T07:24:50Z","receivedAt":"2013-10-12T07:24:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nClearly, a lot of my patches have not been reviewed properly, so even\nthough they are technically correct, and would benefit users, some have\nspecifically been requested by them, and at least one would\nsignificantly improve Git's user interface... they are going nowhere.\n\nHere is the summary, and you can also find a web version:\nhttps://github.com/felipec/git/wiki/My-patches\n\nCheers.\n\n=== branch: improve verbose option ===\n\nPeople have commented that this is a good change, yet it's ignored.\n\n----\nFelipe Contreras (2):\n      branch: trivial cleanup\n      branch: reorganize verbose options\n----\n\nLink: https://github.com/felipec/git/commits/fc/branch/fast +\nPatches: http://mid.gmane.org/1381561229-19947-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Reject non-ff pulls by default (v4) ===\n\nThe conclusion of the discussions is that this change is good, yet it doesn't move forward.\n\n----\nFelipe Contreras (7):\n      pull: rename pull.rename to pull.mode\n      pull: refactor $rebase variable into $mode\n      pull: add --merge option\n      pull: add merge-ff-only option\n      pull: add warning on non-ff merges\n      pull: cleanup documentation\n      pull: add documentation about non-ff merges\n----\n\nLink: https://github.com/felipec/git/commits/fc/pull-merge-ff-only +\nPatches: http://mid.gmane.org/1381561322-20059-1-git-send-email-felipe.contreras@gmail.com +\n\n=== remote-helpers: test reorganization (v2) ===\n\nPeople have requested both that the scripts are autogenerated, and that we\nprovide instructions how to install these for distributions, this fixes both,\nand yet is not merged.\n\n----\nFelipe Contreras (5):\n      remote-helpers: generate scripts\n      build: fix installation of scripts\n      remote-helpers: rename tests\n      remote-helpers: allow direct test execution\n      remote-helpers: add exec-path links\n----\n\nLink: https://github.com/felipec/git/commits/fc/remote/reorg +\nPatches: http://mid.gmane.org/1381561465-20147-1-git-send-email-felipe.contreras@gmail.com +\n\n=== build: add default aliases (v3) ===\n\nAll version control systems out there have default aliases, except Git.\nMercurial even allows overriding the main commands, like 'hg commit' so all the\narguments that use the override of default aliases causing discrepancies as a\nreason to reject this change are void, since clearly Mercurial doesn't have\nsuch problems.\n\n----\nFelipe Contreras (1):\n      build: add default aliases\n----\n\nLink: https://github.com/felipec/git/commits/fc/default-aliases +\nPatches: http://mid.gmane.org/1381561482-20208-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Add core.mode configuration (v3) ===\n\nNot even a reply.\n\n----\nFelipe Contreras (1):\n      Add core.mode configuration\n----\n\nLink: https://github.com/felipec/git/commits/fc/config-mode-next +\nPatches: http://mid.gmane.org/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Officially start moving to the term 'staging area' ===\n\nEverybody agrees this is the way to go, and yet Junio doesn't comment on the way\nforward.\n\n----\nFelipe Contreras (14):\n      Add proper 'stage' command\n      stage: add edit command\n      diff: document --staged\n      grep: add --staged option\n      rm: add --staged option\n      stash: add --stage option to save\n      stash: add --stage to pop and apply\n      submodule: add --staged options\n      apply: add --stage option\n      apply: add --work, --no-work options\n      completion: update --staged options\n      reset: add --stage and --work options\n      reset: allow --keep with --stage\n      completion: update 'git reset' new stage options\n----\n\nLink: https://github.com/felipec/git/commits/fc/stage +\nPatches: http://mid.gmane.org/1381561488-20294-1-git-send-email-felipe.contreras@gmail.com +\n\n=== transport-helper: updates (v3) ===\n\nPeople have requested --foce --dry-run and old:new support for remote helpers,\nthis introduces those options and it was rejected without any reason given.\n\n----\nFelipe Contreras (10):\n      transport-helper: add 'force' to 'export' helpers\n      transport-helper: fix extra lines\n      transport-helper: check for 'forced update' message\n      fast-export: improve argument parsing\n      fast-export: add new --refspec option\n      transport-helper: add support for old:new refspec\n      fast-import: add support to delete refs\n      fast-export: add support to delete refs\n      transport-helper: add support to delete branches\n      transport-helper: don't update refs in dry-run\n----\n\nLink: https://github.com/felipec/git/commits/fc/transport/improv +\nPatches: http://mid.gmane.org/1381561533-20381-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Introduce publish tracking branch ===\n\nThis improves the support for triangular workflows, which even Junio accepted\nis lacking, yet it didn't even receive comments.\n\n----\nFelipe Contreras (8):\n      branch: trivial cleanup\n      branch: reorganize verbose options\n      push: trivial reorganization\n      Add concept of 'publish' branch\n      branch: allow configuring the publish branch\n      t: branch add publish branch tests\n      push: add --set-publish option\n      branch: display publish branch\n----\n\nLink: https://github.com/felipec/git/commits/fc/publish +\nPatches: http://mid.gmane.org/1381561561-20459-1-git-send-email-felipe.contreras@gmail.com +\n\n=== New git-related helper (v10) ===\n\nThis series was included in 'pu' and then silently dropped with no reason\ngiven. 'git contacts' implements a rudimentary version of this, but lacks all\nthe features. I started an external project as a result.\n\n----\nFelipe Contreras (15):\n      Add new git-related helper to contrib\n      contrib: related: add tests\n      contrib: related: add support for multiple patches\n      contrib: related: add option to parse from committish\n      contrib: related: parse committish like format-patch\n      contrib: related: print the amount of involvement\n      contrib: related: add helper Person classes\n      contrib: related: show role count\n      contrib: related: add support for more roles\n      contrib: related: group persons with same email\n      contrib: related: allow usage on other directories\n      contrib: related: add mailmap support\n      contrib: related: add option parsing\n      contrib: related: add option to show commits\n      contrib: related: add README\n----\n\nLink: https://github.com/felipec/git/commits/fc/related +\nPatches: http://mid.gmane.org/1381561584-20529-1-git-send-email-felipe.contreras@gmail.com +\n\n=== fetch: add new fetch.default configuration ===\n\nNo response whatsoever, even after a thorough expalanation of the issue.\n'git fetch .' is still braindead.\n\n----\nFelipe Contreras (1):\n      fetch: add new fetch.default configuration\n----\n\nLink: https://github.com/felipec/git/commits/fc/fetch/default +\nPatches: http://mid.gmane.org/1381561625-20624-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Version fixes and cleanups (v4) ===\n\nOur git.spec is clearly broken for release candidates, and yet the patch\ndoesn't receive feedback.\n\n----\nFelipe Contreras (2):\n      version-gen: cleanup\n      version-gen: fix versions\n----\n\nLink: https://github.com/felipec/git/commits/fc/version-fix +\nPatches: http://mid.gmane.org/1381561628-20665-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Trivial paches ===\n\n----\nFelipe Contreras (20):\n      merge: simplify ff-only option\n      t: replace pulls with merges\n      pull: cleanup documentation\n      fetch: add missing documentation\n      remote: fix trivial memory leak\n      revision: add missing include\n      shortlog: add missing declaration\n      branch: trivial style fix\n      sha1-name: trivial style cleanup\n      doc: git-foo was obsoleted several years ago\n      symbolic-ref: trivial style fix\n      alias: trivial style fix\n      transport-helper: trivial style fix\n      describe: trivial style fixes\n      pretty: trivial style fix\n      revision: trivial style fixes\n      diff: trivial style fix\n      run-command: trivial style fixes\n      setup: trivial style fixes\n      add: avoid yoda conditions\n----\n\nPatches: http://mid.gmane.org/1381561636-20717-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Massive improvents to rebase and cherry-pick (v6) ===\n\nPeople make a fuss that Ruby support is no-go because we need to move scripts\nto C, and when somebody does the work for that, the work gets ignored, even\nthough it's fixing and simplyfing code.\n\n----\nFelipe Contreras (28):\n      cherry-pick: don't barf when there's nothing to do\n      cherry-pick: add --skip-empty option\n      revert/cherry-pick: add --quiet option\n      revert/cherry-pick: add --skip option\n      builtin: add rewrite helper\n      cherry-pick: store rewritten commits\n      cherry-pick: don't store skipped commit\n      builtin: move run_rewrite_hook() to rewrite.c\n      builtin: rewrite: add copy_rewrite_notes()\n      cherry-pick: add --action-name option\n      cherry-pick: copy notes and run hooks\n      cherry-pick: remember rerere-autoupdate\n      rebase: split the cherry-pick stuff\n      rebase: cherry-pick: fix mode storage\n      rebase: cherry-pick: fix sequence continuation\n      rebase: cherry-pick: fix abort of cherry mode\n      rebase: cherry-pick: fix command invocations\n      rebase: cherry-pick: fix status messages\n      rebase: cherry-pick: automatically commit stage\n      rebase: cherry-pick: set correct action-name\n      rebase: trivial cleanup\n      t: rebase-autostash: fix setup\n      sequencer: store progress information\n      prompt: parse cherry-pick rebase mode\n      rebase: use 'cherrypick' mode instead of 'am'\n      rebase: cherry-pick: add merge options\n      rebase: remove merge mode\n      rebase: cherry-pick: add copyright\n----\n\nLink: https://github.com/felipec/git/commits/fc/rebase +\nPatches: http://mid.gmane.org/1377842182-18724-1-git-send-email-felipe.contreras@gmail.com +\n\n=== Support for Ruby (v2) ===\n\nRuby is clearly the way to move forward to replace shell and perl scripts with\nC, with a similar syntax to all three, and yet this comprehensive patch series\ndoesn't even receive a response.\n\n----\nFelipe Contreras (44):\n      Add support for ruby commands\n      ruby: add support for internal ruby programs\n      request-pull: fix annotated tag check\n      request-pull: fix for specific branch\n      request-pull: use appropriate ref\n      request-pull: fix exact match checking\n      request-pull: trivial simplification\n      request-pull: t: trivial whitespace style fixes\n      request-pull: t: add missing cat\n      ruby: rewrite 'request-pull'\n      ruby: request-pull: rewrite perl script\n      ruby: request-pull: trivial simplifications\n      ruby: bind setup_git_directory()\n      ruby: bind dwim_ref()\n      ruby: request-pull: use native dwim_ref()\n      ruby: bind git_config()\n      ruby: request-pull: use native git_config()\n      ruby: bind read_ref()/peel_ref()\n      ruby: bind get_sha1()\n      ruby: request-pull: simplify tag fetching\n      ruby: request-pull: use get_sha1()\n      ruby: add Commit class\n      ruby: bind get_merge_bases()\n      ruby: request-pull: use get_merge_bases()\n      ruby: request-pull: trivial cleanups\n      ruby: bind remote and transport stuff\n      ruby: request-pull: use native remote and transport\n      ruby: bind find_unique_abbrev()\n      ruby: request-pull: use native commit info\n      ruby: bind read_sha1_file()\n      ruby: request-pull: use read_sha1_file()\n      revision: add missing include\n      shortlog: add missing declaration\n      shortlog: split builtin from common code\n      ruby: add RevInfo and DiffOptions\n      ruby: bind shortlog()\n      ruby: request-pull: use shortlog()\n      ruby: bind diff_tree_sha1()\n      ruby: bind log_tree_diff_flush()\n      ruby: request-pull: use native diff_tree stuff\n      ruby: request-pull: remove rescue block\n      ruby: remove GIT_PAGER from environment\n      ruby: add simpler option parser\n      request-pull: rewrite to C\n----\n\nLink: https://github.com/felipec/git/commits/fc/ruby +\nPatches: http://mid.gmane.org/1380405849-13000-11-git-send-email-felipe.contreras@gmail.com +\n\n=== revision: add --except option (v3) ===\n\nAll comments were addressed, yet there doesn't seem to be any path forward.\n\n----\nFelipe Contreras (1):\n      revision: add --except option\n----\n\nLink: https://github.com/felipec/git/commits/fc/revision/except +\nPatches: http://mid.gmane.org/1381561690-20827-1-git-send-email-felipe.contreras@gmail.com +\n\n=== sha1-name: refactor get_sha1() parsing ===\n\nDuy Nguyen suggested that I do this, and now that I do the first step, the work gets ignored.\n\n----\nFelipe Contreras (1):\n      sha1-name: refactor get_sha1() parsing\n----\n\nLink: https://github.com/felipec/git/commits/fc/revision/refactor +\nPatches: http://mid.gmane.org/1381561692-20869-1-git-send-email-felipe.contreras@gmail.com +\n\n-- \nFelipe Contreras\n"},{"id":"228882","messageId":"5247B8D59AAE41F3A0D8BF165D2C2BAE@PhilipOakley","threadId":"35130","inReplyTo":"20131012072450.GA21165@nysa","subject":"Re: My patches","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-10-12T16:18:10Z","receivedAt":"2013-10-12T16:18:10Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" <felipe.contreras@gmail.com>\nSent: Saturday, October 12, 2013 8:24 AM\n> Hi,\n>\n> Clearly, a lot of my patches have not been reviewed properly, so even\n> though they are technically correct, and would benefit users, some \n> have\n> specifically been requested by them, and at least one would\n> significantly improve Git's user interface...\n\nHi Filipe,\n\nGiven you have put a lot of work into your 16 patch series, is there any \nparticular order, or grouping that would help their review.\n\nWith so many patches to consider one (the reviewer(s)) gains another \ntask of simply trying to prioritise the patches (usually one can take \nbig decisions by simply remebering who's series one was interested in).\n\nI expect the clean-ups and 'trivials's' can be managed separately from \nthe 'improvements', which would again be separate from the \"satging\" and \n\"Ruby\" philosophical discussions.\n\n>   they are going nowhere.\nI wouldn't expect 100% success. Every now and again one hears of the \n\"here's some patches I've had in my tree for a while\" that probably had \nthe same early frustrations - they just feel worse the more you produce.\n\n>\n> Here is the summary, and you can also find a web version:\n> https://github.com/felipec/git/wiki/My-patches\n>\n> Cheers.\n>\n\nThanks for the summary.\n Philip\n\n> === branch: improve verbose option ===\n> Felipe Contreras (2):\n> === Reject non-ff pulls by default (v4) ===\n> Felipe Contreras (7):\n> === remote-helpers: test reorganization (v2) ===\n> Felipe Contreras (5):\n> === build: add default aliases (v3) ===\n> Felipe Contreras (1):\n> === Add core.mode configuration (v3) ===\n> Felipe Contreras (1):\n> === Officially start moving to the term 'staging area' ===\n> Felipe Contreras (14):\n> === transport-helper: updates (v3) ===\n> Felipe Contreras (10):\n> === Introduce publish tracking branch ===\n> Felipe Contreras (8):\n> === New git-related helper (v10) ===\n> Felipe Contreras (15):\n> === fetch: add new fetch.default configuration ===\n> Felipe Contreras (1):\n> === Version fixes and cleanups (v4) ===\n> Felipe Contreras (2):\n> === Trivial paches ===\n> Felipe Contreras (20):\n> === Massive improvents to rebase and cherry-pick (v6) ===\n> Felipe Contreras (28):\n> === Support for Ruby (v2) ===\n> Felipe Contreras (44):\n> === revision: add --except option (v3) ===\n> Felipe Contreras (1):\n> === sha1-name: refactor get_sha1() parsing ===\n> Felipe Contreras (1):\n>      sha1-name: refactor get_sha1() parsing\n> -- \n> Felipe Contreras\n> --\n"},{"id":"228891","messageId":"CAMP44s0wWiedCXX-bes5ad6S67pWtyQPcs97y8UQzyUsanMr9Q@mail.gmail.com","threadId":"35130","inReplyTo":"5247B8D59AAE41F3A0D8BF165D2C2BAE@PhilipOakley","subject":"Re: My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-12T22:33:22Z","receivedAt":"2013-10-12T22:33:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Oct 12, 2013 at 11:18 AM, Philip Oakley <philipoakley@iee.org> wrote:\n> From: \"Felipe Contreras\" <felipe.contreras@gmail.com>\n> Sent: Saturday, October 12, 2013 8:24 AM\n\n>> Clearly, a lot of my patches have not been reviewed properly, so even\n>> though they are technically correct, and would benefit users, some have\n>> specifically been requested by them, and at least one would\n>> significantly improve Git's user interface...\n>\n\n> Given you have put a lot of work into your 16 patch series, is there any\n> particular order, or grouping that would help their review.\n\nI ordered them in order of importance, and chance of being merged. For\nexample, the first patch series 'branch: improve verbose option' is\nrelatively simple, it improves things significantly, and other\ndevelopers have already argued this is the way to go. The last one\n'sha1-name: refactor get_sha1() parsing' doesn't have much of a chance\nof being merged, it's quite complicated, there isn't any particular\nchange that is visible to the users, and there isn't probably much\ninterest.\n\n> With so many patches to consider one (the reviewer(s)) gains another task of\n> simply trying to prioritise the patches (usually one can take big decisions\n> by simply remebering who's series one was interested in).\n>\n> I expect the clean-ups and 'trivials's' can be managed separately from the\n> 'improvements', which would again be separate from the \"satging\" and \"Ruby\"\n> philosophical discussions.\n\nMaybe, but the trivial patches have a higher chance of being merged\nthan 'Massive improvents to rebase and cherry-pick' or 'Support for\nRuby', that's why I put them first.\n\n>>   they are going nowhere.\n>\n> I wouldn't expect 100% success. Every now and again one hears of the \"here's\n> some patches I've had in my tree for a while\" that probably had the same\n> early frustrations - they just feel worse the more you produce.\n\nYeah, I'm aware of that, I have contributed to lots of open source\nprojects. However, we are not talking about a couple of patches that\nnow and again get lost, we are talking about 160 patches, some which\nhave gone through several (even ten) iterations. I think that is\ndifferent.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"228936","messageId":"xmqqtxgjg35a.fsf@gitster.dls.corp.google.com","threadId":"35130","inReplyTo":"20131012072450.GA21165@nysa","subject":"Re: My patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-14T17:42:41Z","receivedAt":"2013-10-14T17:42:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Clearly, a lot of my patches have not been reviewed ...\n\nI think the reason for it most likely is because you earned the Bozo\nbit ($gmane/227602) in many reviewers' eyes.\n\nI phrased it differently ($gmane/233347) at the beginning of this\ncycle, but I'll say it one more time. I'll refrain from responding\nto your messages with anything other than \"looks good, thanks\". A\npatch from you that I do not understand the motivation behind it, or\na patch from you that attempts to solve a problem I see better ways\nof solving the same, will not see the usual response from me that\nrequests a clarification (in the resulting code or in its\nexplanation in the proposed commit log message) or suggests an\nimprovement or an alternative.\n\nSuch a review comment and the discussion that follows it after a\npatch is posted is an essential part of the collaborative\ndevelopment process in this community and it has helped the quality\nof our end product. We unfortunately saw time and again that the\nprocess rarely works when the discussion involves your patches. A\nreview thread tends not to conclude with a useful patch but instead\ndescends into an unproductive centithread, frustrating reviewers and\ndiscouraging other people from participating, and ends up draining\nthe energy from everybody involved, which is better spent elsewhere\nto do the real work. It may be reviewers' fault (cf. $gmane/235277),\nor maybe the blame lies elsewhere, but it does not change the fact\nthat we end up wasting a lot of energy without going anywhere.\n\nIn short, responding to your patch that is not a simple \"looks good,\nthanks\" material wastes time, harming the community and hurting our\nusers. That was exactly the reason why you earlier were asked to\nleave ($gmane/227750). So I'll try not to respond to them.\n\nI haven't caught up with the list traffic yet, but the way the\ndiscussion that followed a recent review ($gmane/235936) progressed\ntells me that things haven't improved much, so the assessment above\nstill seems to hold true, at least to me.\n"},{"id":"228950","messageId":"525c64ebe2390_197a905e84c@nysa.notmuch","threadId":"35130","inReplyTo":"xmqqtxgjg35a.fsf@gitster.dls.corp.google.com","subject":"Re: My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-14T21:40:59Z","receivedAt":"2013-10-14T21:40:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> > Clearly, a lot of my patches have not been reviewed ...\n> \n> I think the reason for it most likely is because you earned the Bozo\n> bit ($gmane/227602) in many reviewers' eyes.\n\nSo what you are saying is that the reason is entirely personal, not technical.\nIs that correct?\n\nHowever, it is funny how Theodore Ts'o is saying so in that mail, yet at the\nsame time he is actively engaged in at least two discussions started by me in\ntwo different projects (Linux and isync) just last week.\n\n> I phrased it differently ($gmane/233347) at the beginning of this\n> cycle,\n\nYou said:\n\n---\nIt seems that Matthew is trying to see if you can work better with\nothers than before after a break, but I personally am not hopeful\nyet and do not want to waste my/our time on flamewars like we saw in\nthe past.\n---\n\nBy which you presumably are referring to this patch series:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/233295/focus=233306\n\nIt seems to me there's no negative fallout from that thread, and Matthieu Moy\nstill thinks this is a good series, yet you haven't applied it, or even\ncommented on it.\n\n> but I'll say it one more time. I'll refrain from responding\n> to your messages with anything other than \"looks good, thanks\". A\n> patch from you that I do not understand the motivation behind it, or\n> a patch from you that attempts to solve a problem I see better ways\n> of solving the same, will not see the usual response from me that\n> requests a clarification (in the resulting code or in its\n> explanation in the proposed commit log message) or suggests an\n> improvement or an alternative.\n\nSo, what you are saying is that if none of my 160 patches have been picked yet,\nit means you will not be picking them, even though you are not explicitly\nsaying so. Is that correct?\n\nEven if other Git developers agree it's a good change, you will not be picking\nthem. Correct?\n\n> Such a review comment and the discussion that follows it after a\n> patch is posted is an essential part of the collaborative\n> development process in this community and it has helped the quality\n> of our end product. We unfortunately saw time and again that the\n> process rarely works when the discussion involves your patches.\n\nNo, you did not. What you saw was a person that unlike a trained dog, argued\nagainst you. And apparently your definition of a good discussion is one in\nwhich the other person just does what you say, and doesn't argue back.\n\nLet me be clear; what I did is provide arguments against your arguments, which\nmeans all I did was disagree. That is all.\n\n> I haven't caught up with the list traffic yet, but the way the\n> discussion that followed a recent review ($gmane/235936) progressed\n> tells me that things haven't improved much, so the assessment above\n> still seems to hold true, at least to me.\n\nI applied the change requested in ($gmane/235936), so there is no more comments\nleft on that series, there's nothing that prevents that series from being\npicked, yet it's not.\n\nPresumably you have a problem with that series, but you haven't spoken, and you\nwon't, even though it's not just me that is waiting for a response, but other\nGit developers (and users) who are interested in moving this forward.\n\nAnyway, I spent a lot of time working on those 160 patches, I would appreciate\nif you could respond to this single question:\n\nAre the patches going to be applied? Yes or no.\n\n-- \nFelipe Contreras\n"},{"id":"229134","messageId":"xmqq8uxrzn9h.fsf@gitster.dls.corp.google.com","threadId":"35130","inReplyTo":"525c64ebe2390_197a905e84c@nysa.notmuch","subject":"Re: My patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-17T19:54:34Z","receivedAt":"2013-10-17T19:54:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Such a review comment and the discussion that follows it after a\n>> patch is posted is an essential part of the collaborative\n>> development process in this community and it has helped the quality\n>> of our end product. We unfortunately saw time and again that the\n>> process rarely works when the discussion involves your patches.\n>\n> No, you did not. What you saw was a person that unlike a trained dog, argued\n> against you. And apparently your definition of a good discussion is one in\n> which the other person just does what you say, and doesn't argue back.\n\nThat is so untrue that it is not even funny.  If the ultimate goal\nof your whining is to spread misinformation to make you look like a\nvictim, you are not worth talking to.\n\nContributors often make sensible counter-arguments and/or explain\nthe rationale better than they did in their original messages, and\nthen receive a \"Thanks for a dose of sanity\" (or an equivalent\nphrased in different ways).\n"},{"id":"229146","messageId":"52605a36eef0f_448145fe7466@nysa.notmuch","threadId":"35130","inReplyTo":"xmqq8uxrzn9h.fsf@gitster.dls.corp.google.com","subject":"Re: My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-17T21:44:22Z","receivedAt":"2013-10-17T21:44:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> > Junio C Hamano wrote:\n> >> Such a review comment and the discussion that follows it after a\n> >> patch is posted is an essential part of the collaborative\n> >> development process in this community and it has helped the quality\n> >> of our end product. We unfortunately saw time and again that the\n> >> process rarely works when the discussion involves your patches.\n> >\n> > No, you did not. What you saw was a person that unlike a trained dog, argued\n> > against you. And apparently your definition of a good discussion is one in\n> > which the other person just does what you say, and doesn't argue back.\n> \n> That is so untrue that it is not even funny.\n\nIt is true, and there's penty of evidence that proves it.\n\nEvery single time that you get mad at me, it's because I disagree with you.\n\n> Contributors often make sensible counter-arguments and/or explain\n> the rationale better than they did in their original messages, and\n> then receive a \"Thanks for a dose of sanity\" (or an equivalent\n> phrased in different ways).\n\nYes, when there's an agreement, so you are basically proving what I said. I\ndisagree with you, you disagree with me, and that means I'm the problem.\n\nIn any healthy collaborative project that simply means there was a\ndisagreement, and that's that.\n\n-- \nFelipe Contreras\n"},{"id":"229166","messageId":"9A62D872-0FCF-41B9-B185-7061B25F1CBC@quendi.de","threadId":"35130","inReplyTo":"52605a36eef0f_448145fe7466@nysa.notmuch","subject":"Re: My patches","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-10-18T11:21:07Z","receivedAt":"2013-10-18T11:21:07Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"I guess most other people keep out of this because they are sensible enough to not feed the troll, and instead focus on useful things. But I can't help it, I have to say this.\n\n\nOn 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>> \n>>> Junio C Hamano wrote:\n>>>> Such a review comment and the discussion that follows it after a\n>>>> patch is posted is an essential part of the collaborative\n>>>> development process in this community and it has helped the quality\n>>>> of our end product. We unfortunately saw time and again that the\n>>>> process rarely works when the discussion involves your patches.\n>>> \n>>> No, you did not. What you saw was a person that unlike a trained dog, argued\n>>> against you. And apparently your definition of a good discussion is one in\n>>> which the other person just does what you say, and doesn't argue back.\n>> \n>> That is so untrue that it is not even funny.\n> \n> It is true, and there's penty of evidence that proves it.\n\nNo, it is not true, and there is plenty of evidence that proves it.\n\nBut I don't think it's helpful for either of us drag up such \"evidence\", as it'll convince nobody -- indeed, I am sure almost everybody here has already formed a clear opinion on this matter. And I hazard to guess that the vast majority agree with Junio on this (based, again, on email evidence). Not with you.\n\nOf course one can't prove mathematical theorems by a majority vote, but as we are not talking about theorems, but rather about judging whether Junion's behavior is considered fair or not, I think it is appropriate to. Moreover, if I look at e.g. the \"staging area\" discussion, you also bring up the \"everybody but Junio and one other guy\" argument (incorrectly generalizing from \"those people on this mailing list who chose to reply\" to \"everybody\"), so I think I am entitled to do the same ;-).\n\n(BTW, I am actually in favor of using the term \"staging area\" over \"index\")\n\n\n> Every single time that you get mad at me, it's because I disagree with you.\n\nI have not yet seen Junio get \"mad\" here, even in discussions with you were I think most other people would indeed have gotten \"mad\" at you. He stays remarkably polite, despite the insults and dirt you keep flinging at him... If at all, it would seem that you are getting mad at Junio.\n\n\n> \n>> Contributors often make sensible counter-arguments and/or explain\n>> the rationale better than they did in their original messages, and\n>> then receive a \"Thanks for a dose of sanity\" (or an equivalent\n>> phrased in different ways).\n> \n> Yes, when there's an agreement, so you are basically proving what I said. I\n> disagree with you, you disagree with me, and that means I'm the problem.\n\nActually, it is more like this: \"Felipe disagrees with Junio, Junio disagrees with Felipe, Felipe insults Junio and in passing half a dozen other people.\" It is the latter point which makes the situation asymmetric, and indeed indicates you as the problem.\n\n> In any healthy collaborative project that simply means there was a\n> disagreement, and that's that.\n\nIf your premise was correct (that there is simply a disagreement), then this conclusion might be correct. As it is, though, your premise is false. The problem is rather a disruptive person: you. Quite sad, since you seem to have some good ideas and code contributions! I am in particular grateful for your work on remote helpers, both on specific ones (git-remote-hg) and also on improving the whole remote helper interface. I hope some of this work can eventually be merged...\n\nBut at the end of the day, we most (all?) of us here are volunteers, and unlike what you seem to claim a lot, for most of us, making git better is *not* the number 1 priority in our lives... In particular, if working with you would make git better, but at the same time would give me ulcers, well, my choice is clear to me... Perhaps it wouldn't be best for git, but I don't think anybody (except, perhaps, you) would blame me for it. Or, for that matter, Junio. \n\n\n@Junio: Thank you for being an opinionated but also very fair project lead, who listens to *constructive* feedback, and has again and again demonstrated through action a readiness to revise a position based on sensible discussions conducted on this list.\n\n\n\nMax\n"},{"id":"229167","messageId":"52611e75bdc8d_2b6dcb7e7459@nysa.notmuch","threadId":"35130","inReplyTo":"9A62D872-0FCF-41B9-B185-7061B25F1CBC@quendi.de","subject":"Re: My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-18T11:41:41Z","receivedAt":"2013-10-18T11:41:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Max Horn wrote:\n> I guess most other people keep out of this because they are sensible enough\n> to not feed the troll, and instead focus on useful things. But I can't help\n> it, I have to say this.\n\nYou should probably read the definition of troll:\n\nhttps://en.wikipedia.org/wiki/Troll_(Internet)\n\nUnless you think that contributing useful patches to Git is off-topic, a person\nthat does that by definition cannot be a troll.\n\n> On 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> > Junio C Hamano wrote:\n> >> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> >>> Junio C Hamano wrote:\n> >>>> Such a review comment and the discussion that follows it after a\n> >>>> patch is posted is an essential part of the collaborative\n> >>>> development process in this community and it has helped the quality\n> >>>> of our end product. We unfortunately saw time and again that the\n> >>>> process rarely works when the discussion involves your patches.\n> >>> \n> >>> No, you did not. What you saw was a person that unlike a trained dog, argued\n> >>> against you. And apparently your definition of a good discussion is one in\n> >>> which the other person just does what you say, and doesn't argue back.\n> >> \n> >> That is so untrue that it is not even funny.\n> > \n> > It is true, and there's penty of evidence that proves it.\n> \n> No, it is not true, and there is plenty of evidence that proves it.\n> \n> But I don't think it's helpful for either of us drag up such \"evidence\", as\n> it'll convince nobody -- indeed, I am sure almost everybody here has already\n> formed a clear opinion on this matter.\n\nThat's why I didn't bring it up.\n\n> And I hazard to guess that the vast majority agree with Junio on this (based,\n> again, on email evidence). Not with you.\n\nThat is irrelevant, and a fallacy. The vast majority of people thought the\nEarth was the center of the universe, and they were all wrong.\n\nIt's called ad populum fallacy, look it up. Wether the majority of Git\ndevelopers agree that there's something more than a disagreement is irrelevant,\ntheir opinion doesn't change the truth.\n\nAnd by the way, a disregard for evidence is a clear sign of a person that is\nnot interested in the truth.\n\n> Of course one can't prove mathematical theorems by a majority vote, but as we\n> are not talking about theorems, but rather about judging whether Junion's\n> behavior is considered fair or not, I think it is appropriate to.\n\nNo, that's not what we are talking about.\n\nMy claim is that all I did was disagree with Junio. You can invalidate that\nclaim easily by providing *a single* example where I did more than disagree.\n\n> Moreover, if I look at e.g. the \"staging area\" discussion, you also bring up\n> the \"everybody but Junio and one other guy\" argument (incorrectly\n> generalizing from \"those people on this mailing list who chose to reply\" to\n> \"everybody\"), so I think I am entitled to do the same ;-).\n\nI've stated multiple times that by \"everybody\" I mean \"virtually everybody\".\nSince Junio has accepted that \"the index\" is not the best term, \"virtually\neverybody\" is actually everybody that has voiced an opinion, except one single\nperson.\n\n> > Every single time that you get mad at me, it's because I disagree with you.\n> \n> I have not yet seen Junio get \"mad\" here, even in discussions with you were I\n> think most other people would indeed have gotten \"mad\" at you.\n\nI can provide the evidence when Junio has become clearly \"mad\"... If you are\ninterested in the truth that is.\n\n> He stays remarkably polite, despite the insults and dirt you keep flinging at\n> him...  If at all, it would seem that you are getting mad at Junio.\n\nThat is pure libel. Show me *one* example where I threw an insult, or \"dirt\".\n\n> >> Contributors often make sensible counter-arguments and/or explain\n> >> the rationale better than they did in their original messages, and\n> >> then receive a \"Thanks for a dose of sanity\" (or an equivalent\n> >> phrased in different ways).\n> > \n> > Yes, when there's an agreement, so you are basically proving what I said. I\n> > disagree with you, you disagree with me, and that means I'm the problem.\n> \n> Actually, it is more like this: \"Felipe disagrees with Junio, Junio disagrees\n> with Felipe, Felipe insults Junio and in passing half a dozen other people.\"\n\nLies. When did I insult anybody?\n\n> > In any healthy collaborative project that simply means there was a\n> > disagreement, and that's that.\n> \n> If your premise was correct (that there is simply a disagreement), then this\n> conclusion might be correct. As it is, though, your premise is false.\n\nEvidence, or that claim is dismissed.\n\nThat which can be asserted without evidence can be dismissed without evidence.\n\n> The problem is rather a disruptive person: you.\n\nNelson Mandela was considered a \"disruptive person\" (a terrorist[1]), yet\nvirtually everyone agrees that the problem was not him, but the system that\nlabeled him as such.\n\n[1] http://en.wikinews.org/wiki/Nelson_Mandela_taken_off_US_terrorist_list\n\n-- \nFelipe Contreras\n"},{"id":"229174","messageId":"20131018153009.GA23704@thunk.org","threadId":"35130","inReplyTo":"52611e75bdc8d_2b6dcb7e7459@nysa.notmuch","subject":"Re: My patches","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-10-18T15:30:09Z","receivedAt":"2013-10-18T15:30:09Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:\n> > And I hazard to guess that the vast majority agree with Junio on this (based,\n> > again, on email evidence). Not with you.\n> \n> That is irrelevant, and a fallacy. The vast majority of people thought the\n> Earth was the center of the universe, and they were all wrong.\n> \n> It's called ad populum fallacy, look it up. Wether the majority of Git\n> developers agree that there's something more than a disagreement is irrelevant,\n> their opinion doesn't change the truth.\n\nLook, the problem is that you insist on being \"right\", even on matters\nwhich may be more about taste and preference than anything that can be\nproven mathematically.  Worse, you insist on trying to convince people\neven when it might be better to just give up and decide that maybe\nsomething not's worth the effort to get the last word in.  This is how\nwe get to centithreads.  If every time someone disagrees, you insist\non replying, and then if people give up in disgust, you then try to\nuse that as \"proof\" that you must be right, since you've dazzled them\nwith your brilliance, that's not good for the development community.\n\nSometimes a question is important enough that it's worth doing this.\nBut I'd suggest to you that you should ask yourself whether you're\ndoing it too often.\n\nAfter all, this is open source.  If you are convinced that you are\nright, and everyone else in the community is wrong, it is within your\npower to fork the code base, and to prove us wrong by creating a\nbetter product.\n\nOr you can decide to just keep a patch set to yourself, or perhaps\npost it periodically, if it is some key feature that you are certain\nyou or your company can't live with out.  Heck, I've done this with\next4, even though I'm the maintainer --- there have been features that\nI know are critical for my company, but the rest of the ext4\ndevelopment community are stridently against.  I've just simply posted\nthe patch set once, and if it gets strongly opposed, I'll just keep it\nas a out-of-tree patch.\n\nThe fallocate NO_HIDE_STALE flag is a good example of that; it's used\nin production on thousands and thousands of servers by Google and Tao\nBao, but since there was strong opposition on the ext4 list, we've\nkept it as an out-of-tree patch.  Note what I did not do.  I did not\nforce the patch in, even though it might be within my power as the\nmaintainer; nor did I try to convince people over and OVER and OVER\nagain about the rightness of my position, and turn it into a\ncentithread.\n\n> My claim is that all I did was disagree with Junio. You can invalidate that\n> claim easily by providing *a single* example where I did more than disagree.\n\nThe problem is when you disagree with a number of people (not just\nJunio), and you are, in my opinion, overly persistent.  We can argue\nwhether you've stepped over the line in terms of impugning people's\nmotives or sanity, but that's not necessarily the most important\nissue.  People sometimes step over the line, and while that's\nunfortunate, it's when it becomes a persistent pattern, and it happens\nfrequently enough, that it becomes a real problem.\n\nAlternatively, if you are right that Junio is mad, and he's being\ncapriciously insulting, then I'm sure that when you establish your own\nfork, lots of developers will come flocking to your flag.  If they do\nnot, then perhaps you might want to take that as some objective\nevidence that the community is perhaps, more willing to work with him,\nthen they are to work with you.\n\nBest regards,\n\n\t\t\t\t\t\t- Ted\n\nP.S.  There are plenty of things that I consider to be unfortunate\nabout git's command line interface, in terms of inconsistencies and\nconfusing terminology.  Over the past 5+ years, I've observed that I\nthink the way commit selection in \"git format-patch\" is inconsistent\nwith how we handle commit selection for other commands, e.g., \"git log\n<commit>\" vs and \"git format-patch <commit>\".  Even if you think that\nthis is a matter of self-inherent \"truth\", versus just a matter of\ntaste, there is also the consideration of backwards compatibility, and\nthe question of how important consistency and easy of learning gets\ntraded off against backwards compatibility and invalidating\npotentially huge numbers of shell scripts and documentation.  So it's\nnot something where I've made a nuisance of myself, because it's a\nsettled issue.\n\nAs another example, people have agreed for a long time that the fact\nthat tab characters are significant in Makefiles is highly\nunfortunate.  However, no one is running around calling the GNU Make\nmaintainers \"insane\" for not being willing to make a change that would\nbreak huge numbers of Makefiles in the world.  More importantly,\npeople aren't brining up the same subject over and over and over again\non the GNU Makefile mailing list.  Perhaps you might consider what\nwould be the appropriate response if someone insisteted on creating\ncentithreads on the GNU Makefile discuss list on that subject.\n"},{"id":"229178","messageId":"5261589c855ea_30ce11dbe78d3@nysa.notmuch","threadId":"35130","inReplyTo":"20131018153009.GA23704@thunk.org","subject":"Re: My patches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-18T15:49:48Z","receivedAt":"2013-10-18T15:49:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Theodore Ts'o wrote:\n> On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:\n> > > And I hazard to guess that the vast majority agree with Junio on this (based,\n> > > again, on email evidence). Not with you.\n> > \n> > That is irrelevant, and a fallacy. The vast majority of people thought the\n> > Earth was the center of the universe, and they were all wrong.\n> > \n> > It's called ad populum fallacy, look it up. Wether the majority of Git\n> > developers agree that there's something more than a disagreement is irrelevant,\n> > their opinion doesn't change the truth.\n> \n> Look, the problem is that you insist on being \"right\", even on matters which\n> may be more about taste and preference than anything that can be proven\n> mathematically.\n\nI don't insist on being right, I have an opinion and I voice it, there is\nnothing wrong with that. If the other side agrees there's a difference of\nopinion, that's the end of the discussion.\n\nI would say it's actually the other side that insists on being right, and\nthat's the problem; they don't agree it's a difference in opinion, from their\npoint of one side is right, and the other side is wrong, and that's what causes\ntheir frustration.\n\nAsk Junio if he thinks it's simply a matter of a difference in opinion. He\npretty much already said it's not.\n\n> Worse, you insist on trying to convince people even when it might be better\n> to just give up and decide that maybe something not's worth the effort to get\n> the last word in.  This is how we get to centithreads.  If every time someone\n> disagrees, you insist on replying,\n\nThis is how it goes:\n\n 1) Side A\n 2) Side B\n\n 3) Side A\n 4) Side B\n\n 5) Side A\n 6) Side B\n\nAt any point in time side B could stop replying, sure, but so could side A.\n\nWhy do you blame ME for replying, and not the other side, for replying to my\nreply?\n\nPresumably because right before reply 4), side A thought the discussion was\nwortwhile, and something happened in 5) that changed their opinion, and now\nside B becomes a problematic person. And since you are friends with side A, you\ntake their side.\n\n> and then if people give up in disgust, you then try to use that as \"proof\"\n> that you must be right,\n\nShow me *one* instance when I have done so. I have never used silence as\nevidence of anything.\n\n> Sometimes a question is important enough that it's worth doing this.\n> But I'd suggest to you that you should ask yourself whether you're\n> doing it too often.\n> \n> After all, this is open source.  If you are convinced that you are\n> right, and everyone else in the community is wrong, it is within your\n> power to fork the code base, and to prove us wrong by creating a\n> better product.\n\nDon't worry, that is *exactly* what I plan to do.\n\n> The fallocate NO_HIDE_STALE flag is a good example of that; it's used\n> in production on thousands and thousands of servers by Google and Tao\n> Bao, but since there was strong opposition on the ext4 list, we've\n> kept it as an out-of-tree patch.  Note what I did not do.  I did not\n> force the patch in, even though it might be within my power as the\n> maintainer; nor did I try to convince people over and OVER and OVER\n> again about the rightness of my position, and turn it into a\n> centithread.\n\nMy patches are not good just for me or my company, they are good for everyone.\n\nHave you actually looked at any of them?\n\n> > My claim is that all I did was disagree with Junio. You can invalidate that\n> > claim easily by providing *a single* example where I did more than\n> > disagree.\n> \n> The problem is when you disagree with a number of people (not just\n> Junio), and you are, in my opinion, overly persistent.\n\nBut that's not what Junio said. This is the second time you defend Junio by\nassuming his position is exactly the opposite.\n\nJunio doesn't think it's just a disagreement, Junio doesn't think I'm just\nbeing persistent, Junio is saying I can't be worked with.\n\nThe interesting thing is that when Junio agrees with the change, he can work\nwith me, when I agree my change is not good, the same, but suddenly when I\ndon't agree, then I'm not good to work with. See the pattern?\n\n> We can argue whether you've stepped over the line in terms of impugning\n> people's motives or sanity, but that's not necessarily the most important\n> issue.  People sometimes step over the line, and while that's unfortunate,\n> it's when it becomes a persistent pattern, and it happens frequently enough,\n> that it becomes a real problem.\n\nHave I ever impugned people's motives or sanity? Please, show me where I did that.\n\n> Alternatively, if you are right that Junio is mad,\n\nI didn't say Junio is mad, I said he got mad.\n\n:  carried away by intense anger :  furious <mad about the delay>\n\nhttp://www.merriam-webster.com/dictionary/mad\n\n> and he's being capriciously insulting, then I'm sure that when you establish\n> your own fork, lots of developers will come flocking to your flag.  If they\n> do not, then perhaps you might want to take that as some objective evidence\n> that the community is perhaps, more willing to work with him, then they are\n> to work with you.\n\nIf you know anything about rationality you know that correlation doesn't prove\ncausation. So no, it would not be objective evidence.\n\n-- \nFelipe Contreras\n"},{"id":"229179","messageId":"xmqqtxgewm4i.fsf@gitster.dls.corp.google.com","threadId":"35130","inReplyTo":"20131018153009.GA23704@thunk.org","subject":"Re: My patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-18T16:59:41Z","receivedAt":"2013-10-18T16:59:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o <tytso@mit.edu> writes:\n\n> Over the past 5+ years, I've observed that I\n> think the way commit selection in \"git format-patch\" is inconsistent\n> with how we handle commit selection for other commands, e.g., \"git log\n> <commit>\" vs and \"git format-patch <commit>\".  Even if you think that\n> this is a matter of self-inherent \"truth\", versus just a matter of\n> taste, there is also the consideration of backwards compatibility, and\n> the question of how important consistency and easy of learning gets\n> traded off against backwards compatibility and invalidating\n> potentially huge numbers of shell scripts and documentation.  So it's\n> not something where I've made a nuisance of myself, because it's a\n> settled issue.\n\nThe original syntax to select of commits by format-patch is very\ninconsistent from the log family because it was done way before the\nlog family's way has been established as the best practice. It has\nannoyed enough people that we spent effort to teach recent Git\nto accept\n\n\t$ git format-patch master..next\n\nas well.\n\nSo it indeed is a settled issue, but you are correct to point out\nthat we had to find a way to do so while still keeping the original\nsyntax working for people who have scripts and people who work from\nrandom and stale documents we have not much control over updating.\n"}]}