* My patches @ 2013-10-12 7:24 Felipe Contreras 2013-10-12 16:18 ` Philip Oakley 2013-10-14 17:42 ` Junio C Hamano 0 siblings, 2 replies; 12+ messages in thread From: Felipe Contreras @ 2013-10-12 7:24 UTC (permalink / raw) To: git Hi, Clearly, a lot of my patches have not been reviewed properly, so even though they are technically correct, and would benefit users, some have specifically been requested by them, and at least one would significantly improve Git's user interface... they are going nowhere. Here is the summary, and you can also find a web version: https://github.com/felipec/git/wiki/My-patches Cheers. === branch: improve verbose option === People have commented that this is a good change, yet it's ignored. ---- Felipe Contreras (2): branch: trivial cleanup branch: reorganize verbose options ---- Link: https://github.com/felipec/git/commits/fc/branch/fast + Patches: http://mid.gmane.org/1381561229-19947-1-git-send-email-felipe.contreras@gmail.com + === Reject non-ff pulls by default (v4) === The conclusion of the discussions is that this change is good, yet it doesn't move forward. ---- Felipe Contreras (7): pull: rename pull.rename to pull.mode pull: refactor $rebase variable into $mode pull: add --merge option pull: add merge-ff-only option pull: add warning on non-ff merges pull: cleanup documentation pull: add documentation about non-ff merges ---- Link: https://github.com/felipec/git/commits/fc/pull-merge-ff-only + Patches: http://mid.gmane.org/1381561322-20059-1-git-send-email-felipe.contreras@gmail.com + === remote-helpers: test reorganization (v2) === People have requested both that the scripts are autogenerated, and that we provide instructions how to install these for distributions, this fixes both, and yet is not merged. ---- Felipe Contreras (5): remote-helpers: generate scripts build: fix installation of scripts remote-helpers: rename tests remote-helpers: allow direct test execution remote-helpers: add exec-path links ---- Link: https://github.com/felipec/git/commits/fc/remote/reorg + Patches: http://mid.gmane.org/1381561465-20147-1-git-send-email-felipe.contreras@gmail.com + === build: add default aliases (v3) === All version control systems out there have default aliases, except Git. Mercurial even allows overriding the main commands, like 'hg commit' so all the arguments that use the override of default aliases causing discrepancies as a reason to reject this change are void, since clearly Mercurial doesn't have such problems. ---- Felipe Contreras (1): build: add default aliases ---- Link: https://github.com/felipec/git/commits/fc/default-aliases + Patches: http://mid.gmane.org/1381561482-20208-1-git-send-email-felipe.contreras@gmail.com + === Add core.mode configuration (v3) === Not even a reply. ---- Felipe Contreras (1): Add core.mode configuration ---- Link: https://github.com/felipec/git/commits/fc/config-mode-next + Patches: http://mid.gmane.org/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com + === Officially start moving to the term 'staging area' === Everybody agrees this is the way to go, and yet Junio doesn't comment on the way forward. ---- Felipe Contreras (14): Add proper 'stage' command stage: add edit command diff: document --staged grep: add --staged option rm: add --staged option stash: add --stage option to save stash: add --stage to pop and apply submodule: add --staged options apply: add --stage option apply: add --work, --no-work options completion: update --staged options reset: add --stage and --work options reset: allow --keep with --stage completion: update 'git reset' new stage options ---- Link: https://github.com/felipec/git/commits/fc/stage + Patches: http://mid.gmane.org/1381561488-20294-1-git-send-email-felipe.contreras@gmail.com + === transport-helper: updates (v3) === People have requested --foce --dry-run and old:new support for remote helpers, this introduces those options and it was rejected without any reason given. ---- Felipe Contreras (10): transport-helper: add 'force' to 'export' helpers transport-helper: fix extra lines transport-helper: check for 'forced update' message fast-export: improve argument parsing fast-export: add new --refspec option transport-helper: add support for old:new refspec fast-import: add support to delete refs fast-export: add support to delete refs transport-helper: add support to delete branches transport-helper: don't update refs in dry-run ---- Link: https://github.com/felipec/git/commits/fc/transport/improv + Patches: http://mid.gmane.org/1381561533-20381-1-git-send-email-felipe.contreras@gmail.com + === Introduce publish tracking branch === This improves the support for triangular workflows, which even Junio accepted is lacking, yet it didn't even receive comments. ---- Felipe Contreras (8): branch: trivial cleanup branch: reorganize verbose options push: trivial reorganization Add concept of 'publish' branch branch: allow configuring the publish branch t: branch add publish branch tests push: add --set-publish option branch: display publish branch ---- Link: https://github.com/felipec/git/commits/fc/publish + Patches: http://mid.gmane.org/1381561561-20459-1-git-send-email-felipe.contreras@gmail.com + === New git-related helper (v10) === This series was included in 'pu' and then silently dropped with no reason given. 'git contacts' implements a rudimentary version of this, but lacks all the features. I started an external project as a result. ---- Felipe Contreras (15): Add new git-related helper to contrib contrib: related: add tests contrib: related: add support for multiple patches contrib: related: add option to parse from committish contrib: related: parse committish like format-patch contrib: related: print the amount of involvement contrib: related: add helper Person classes contrib: related: show role count contrib: related: add support for more roles contrib: related: group persons with same email contrib: related: allow usage on other directories contrib: related: add mailmap support contrib: related: add option parsing contrib: related: add option to show commits contrib: related: add README ---- Link: https://github.com/felipec/git/commits/fc/related + Patches: http://mid.gmane.org/1381561584-20529-1-git-send-email-felipe.contreras@gmail.com + === fetch: add new fetch.default configuration === No response whatsoever, even after a thorough expalanation of the issue. 'git fetch .' is still braindead. ---- Felipe Contreras (1): fetch: add new fetch.default configuration ---- Link: https://github.com/felipec/git/commits/fc/fetch/default + Patches: http://mid.gmane.org/1381561625-20624-1-git-send-email-felipe.contreras@gmail.com + === Version fixes and cleanups (v4) === Our git.spec is clearly broken for release candidates, and yet the patch doesn't receive feedback. ---- Felipe Contreras (2): version-gen: cleanup version-gen: fix versions ---- Link: https://github.com/felipec/git/commits/fc/version-fix + Patches: http://mid.gmane.org/1381561628-20665-1-git-send-email-felipe.contreras@gmail.com + === Trivial paches === ---- Felipe Contreras (20): merge: simplify ff-only option t: replace pulls with merges pull: cleanup documentation fetch: add missing documentation remote: fix trivial memory leak revision: add missing include shortlog: add missing declaration branch: trivial style fix sha1-name: trivial style cleanup doc: git-foo was obsoleted several years ago symbolic-ref: trivial style fix alias: trivial style fix transport-helper: trivial style fix describe: trivial style fixes pretty: trivial style fix revision: trivial style fixes diff: trivial style fix run-command: trivial style fixes setup: trivial style fixes add: avoid yoda conditions ---- Patches: http://mid.gmane.org/1381561636-20717-1-git-send-email-felipe.contreras@gmail.com + === Massive improvents to rebase and cherry-pick (v6) === People make a fuss that Ruby support is no-go because we need to move scripts to C, and when somebody does the work for that, the work gets ignored, even though it's fixing and simplyfing code. ---- Felipe Contreras (28): cherry-pick: don't barf when there's nothing to do cherry-pick: add --skip-empty option revert/cherry-pick: add --quiet option revert/cherry-pick: add --skip option builtin: add rewrite helper cherry-pick: store rewritten commits cherry-pick: don't store skipped commit builtin: move run_rewrite_hook() to rewrite.c builtin: rewrite: add copy_rewrite_notes() cherry-pick: add --action-name option cherry-pick: copy notes and run hooks cherry-pick: remember rerere-autoupdate rebase: split the cherry-pick stuff rebase: cherry-pick: fix mode storage rebase: cherry-pick: fix sequence continuation rebase: cherry-pick: fix abort of cherry mode rebase: cherry-pick: fix command invocations rebase: cherry-pick: fix status messages rebase: cherry-pick: automatically commit stage rebase: cherry-pick: set correct action-name rebase: trivial cleanup t: rebase-autostash: fix setup sequencer: store progress information prompt: parse cherry-pick rebase mode rebase: use 'cherrypick' mode instead of 'am' rebase: cherry-pick: add merge options rebase: remove merge mode rebase: cherry-pick: add copyright ---- Link: https://github.com/felipec/git/commits/fc/rebase + Patches: http://mid.gmane.org/1377842182-18724-1-git-send-email-felipe.contreras@gmail.com + === Support for Ruby (v2) === Ruby is clearly the way to move forward to replace shell and perl scripts with C, with a similar syntax to all three, and yet this comprehensive patch series doesn't even receive a response. ---- Felipe Contreras (44): Add support for ruby commands ruby: add support for internal ruby programs request-pull: fix annotated tag check request-pull: fix for specific branch request-pull: use appropriate ref request-pull: fix exact match checking request-pull: trivial simplification request-pull: t: trivial whitespace style fixes request-pull: t: add missing cat ruby: rewrite 'request-pull' ruby: request-pull: rewrite perl script ruby: request-pull: trivial simplifications ruby: bind setup_git_directory() ruby: bind dwim_ref() ruby: request-pull: use native dwim_ref() ruby: bind git_config() ruby: request-pull: use native git_config() ruby: bind read_ref()/peel_ref() ruby: bind get_sha1() ruby: request-pull: simplify tag fetching ruby: request-pull: use get_sha1() ruby: add Commit class ruby: bind get_merge_bases() ruby: request-pull: use get_merge_bases() ruby: request-pull: trivial cleanups ruby: bind remote and transport stuff ruby: request-pull: use native remote and transport ruby: bind find_unique_abbrev() ruby: request-pull: use native commit info ruby: bind read_sha1_file() ruby: request-pull: use read_sha1_file() revision: add missing include shortlog: add missing declaration shortlog: split builtin from common code ruby: add RevInfo and DiffOptions ruby: bind shortlog() ruby: request-pull: use shortlog() ruby: bind diff_tree_sha1() ruby: bind log_tree_diff_flush() ruby: request-pull: use native diff_tree stuff ruby: request-pull: remove rescue block ruby: remove GIT_PAGER from environment ruby: add simpler option parser request-pull: rewrite to C ---- Link: https://github.com/felipec/git/commits/fc/ruby + Patches: http://mid.gmane.org/1380405849-13000-11-git-send-email-felipe.contreras@gmail.com + === revision: add --except option (v3) === All comments were addressed, yet there doesn't seem to be any path forward. ---- Felipe Contreras (1): revision: add --except option ---- Link: https://github.com/felipec/git/commits/fc/revision/except + Patches: http://mid.gmane.org/1381561690-20827-1-git-send-email-felipe.contreras@gmail.com + === sha1-name: refactor get_sha1() parsing === Duy Nguyen suggested that I do this, and now that I do the first step, the work gets ignored. ---- Felipe Contreras (1): sha1-name: refactor get_sha1() parsing ---- Link: https://github.com/felipec/git/commits/fc/revision/refactor + Patches: http://mid.gmane.org/1381561692-20869-1-git-send-email-felipe.contreras@gmail.com + -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-12 7:24 My patches Felipe Contreras @ 2013-10-12 16:18 ` Philip Oakley 2013-10-12 22:33 ` Felipe Contreras 2013-10-14 17:42 ` Junio C Hamano 1 sibling, 1 reply; 12+ messages in thread From: Philip Oakley @ 2013-10-12 16:18 UTC (permalink / raw) To: Felipe Contreras, git From: "Felipe Contreras" <felipe.contreras@gmail.com> Sent: Saturday, October 12, 2013 8:24 AM > Hi, > > Clearly, a lot of my patches have not been reviewed properly, so even > though they are technically correct, and would benefit users, some > have > specifically been requested by them, and at least one would > significantly improve Git's user interface... Hi Filipe, Given you have put a lot of work into your 16 patch series, is there any particular order, or grouping that would help their review. With so many patches to consider one (the reviewer(s)) gains another task of simply trying to prioritise the patches (usually one can take big decisions by simply remebering who's series one was interested in). I expect the clean-ups and 'trivials's' can be managed separately from the 'improvements', which would again be separate from the "satging" and "Ruby" philosophical discussions. > they are going nowhere. I wouldn't expect 100% success. Every now and again one hears of the "here's some patches I've had in my tree for a while" that probably had the same early frustrations - they just feel worse the more you produce. > > Here is the summary, and you can also find a web version: > https://github.com/felipec/git/wiki/My-patches > > Cheers. > Thanks for the summary. Philip > === branch: improve verbose option === > Felipe Contreras (2): > === Reject non-ff pulls by default (v4) === > Felipe Contreras (7): > === remote-helpers: test reorganization (v2) === > Felipe Contreras (5): > === build: add default aliases (v3) === > Felipe Contreras (1): > === Add core.mode configuration (v3) === > Felipe Contreras (1): > === Officially start moving to the term 'staging area' === > Felipe Contreras (14): > === transport-helper: updates (v3) === > Felipe Contreras (10): > === Introduce publish tracking branch === > Felipe Contreras (8): > === New git-related helper (v10) === > Felipe Contreras (15): > === fetch: add new fetch.default configuration === > Felipe Contreras (1): > === Version fixes and cleanups (v4) === > Felipe Contreras (2): > === Trivial paches === > Felipe Contreras (20): > === Massive improvents to rebase and cherry-pick (v6) === > Felipe Contreras (28): > === Support for Ruby (v2) === > Felipe Contreras (44): > === revision: add --except option (v3) === > Felipe Contreras (1): > === sha1-name: refactor get_sha1() parsing === > Felipe Contreras (1): > sha1-name: refactor get_sha1() parsing > -- > Felipe Contreras > -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-12 16:18 ` Philip Oakley @ 2013-10-12 22:33 ` Felipe Contreras 0 siblings, 0 replies; 12+ messages in thread From: Felipe Contreras @ 2013-10-12 22:33 UTC (permalink / raw) To: Philip Oakley; +Cc: git On Sat, Oct 12, 2013 at 11:18 AM, Philip Oakley <philipoakley@iee.org> wrote: > From: "Felipe Contreras" <felipe.contreras@gmail.com> > Sent: Saturday, October 12, 2013 8:24 AM >> Clearly, a lot of my patches have not been reviewed properly, so even >> though they are technically correct, and would benefit users, some have >> specifically been requested by them, and at least one would >> significantly improve Git's user interface... > > Given you have put a lot of work into your 16 patch series, is there any > particular order, or grouping that would help their review. I ordered them in order of importance, and chance of being merged. For example, the first patch series 'branch: improve verbose option' is relatively simple, it improves things significantly, and other developers have already argued this is the way to go. The last one 'sha1-name: refactor get_sha1() parsing' doesn't have much of a chance of being merged, it's quite complicated, there isn't any particular change that is visible to the users, and there isn't probably much interest. > With so many patches to consider one (the reviewer(s)) gains another task of > simply trying to prioritise the patches (usually one can take big decisions > by simply remebering who's series one was interested in). > > I expect the clean-ups and 'trivials's' can be managed separately from the > 'improvements', which would again be separate from the "satging" and "Ruby" > philosophical discussions. Maybe, but the trivial patches have a higher chance of being merged than 'Massive improvents to rebase and cherry-pick' or 'Support for Ruby', that's why I put them first. >> they are going nowhere. > > I wouldn't expect 100% success. Every now and again one hears of the "here's > some patches I've had in my tree for a while" that probably had the same > early frustrations - they just feel worse the more you produce. Yeah, I'm aware of that, I have contributed to lots of open source projects. However, we are not talking about a couple of patches that now and again get lost, we are talking about 160 patches, some which have gone through several (even ten) iterations. I think that is different. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-12 7:24 My patches Felipe Contreras 2013-10-12 16:18 ` Philip Oakley @ 2013-10-14 17:42 ` Junio C Hamano 2013-10-14 21:40 ` Felipe Contreras 1 sibling, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2013-10-14 17:42 UTC (permalink / raw) To: Felipe Contreras; +Cc: git Felipe Contreras <felipe.contreras@gmail.com> writes: > Clearly, a lot of my patches have not been reviewed ... I think the reason for it most likely is because you earned the Bozo bit ($gmane/227602) in many reviewers' eyes. I phrased it differently ($gmane/233347) at the beginning of this cycle, but I'll say it one more time. I'll refrain from responding to your messages with anything other than "looks good, thanks". A patch from you that I do not understand the motivation behind it, or a patch from you that attempts to solve a problem I see better ways of solving the same, will not see the usual response from me that requests a clarification (in the resulting code or in its explanation in the proposed commit log message) or suggests an improvement or an alternative. Such a review comment and the discussion that follows it after a patch is posted is an essential part of the collaborative development process in this community and it has helped the quality of our end product. We unfortunately saw time and again that the process rarely works when the discussion involves your patches. A review thread tends not to conclude with a useful patch but instead descends into an unproductive centithread, frustrating reviewers and discouraging other people from participating, and ends up draining the energy from everybody involved, which is better spent elsewhere to do the real work. It may be reviewers' fault (cf. $gmane/235277), or maybe the blame lies elsewhere, but it does not change the fact that we end up wasting a lot of energy without going anywhere. In short, responding to your patch that is not a simple "looks good, thanks" material wastes time, harming the community and hurting our users. That was exactly the reason why you earlier were asked to leave ($gmane/227750). So I'll try not to respond to them. I haven't caught up with the list traffic yet, but the way the discussion that followed a recent review ($gmane/235936) progressed tells me that things haven't improved much, so the assessment above still seems to hold true, at least to me. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-14 17:42 ` Junio C Hamano @ 2013-10-14 21:40 ` Felipe Contreras 2013-10-17 19:54 ` Junio C Hamano 0 siblings, 1 reply; 12+ messages in thread From: Felipe Contreras @ 2013-10-14 21:40 UTC (permalink / raw) To: Junio C Hamano, Felipe Contreras; +Cc: git Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > Clearly, a lot of my patches have not been reviewed ... > > I think the reason for it most likely is because you earned the Bozo > bit ($gmane/227602) in many reviewers' eyes. So what you are saying is that the reason is entirely personal, not technical. Is that correct? However, it is funny how Theodore Ts'o is saying so in that mail, yet at the same time he is actively engaged in at least two discussions started by me in two different projects (Linux and isync) just last week. > I phrased it differently ($gmane/233347) at the beginning of this > cycle, You said: --- It seems that Matthew is trying to see if you can work better with others than before after a break, but I personally am not hopeful yet and do not want to waste my/our time on flamewars like we saw in the past. --- By which you presumably are referring to this patch series: http://thread.gmane.org/gmane.comp.version-control.git/233295/focus=233306 It seems to me there's no negative fallout from that thread, and Matthieu Moy still thinks this is a good series, yet you haven't applied it, or even commented on it. > but I'll say it one more time. I'll refrain from responding > to your messages with anything other than "looks good, thanks". A > patch from you that I do not understand the motivation behind it, or > a patch from you that attempts to solve a problem I see better ways > of solving the same, will not see the usual response from me that > requests a clarification (in the resulting code or in its > explanation in the proposed commit log message) or suggests an > improvement or an alternative. So, what you are saying is that if none of my 160 patches have been picked yet, it means you will not be picking them, even though you are not explicitly saying so. Is that correct? Even if other Git developers agree it's a good change, you will not be picking them. Correct? > Such a review comment and the discussion that follows it after a > patch is posted is an essential part of the collaborative > development process in this community and it has helped the quality > of our end product. We unfortunately saw time and again that the > process rarely works when the discussion involves your patches. No, you did not. What you saw was a person that unlike a trained dog, argued against you. And apparently your definition of a good discussion is one in which the other person just does what you say, and doesn't argue back. Let me be clear; what I did is provide arguments against your arguments, which means all I did was disagree. That is all. > I haven't caught up with the list traffic yet, but the way the > discussion that followed a recent review ($gmane/235936) progressed > tells me that things haven't improved much, so the assessment above > still seems to hold true, at least to me. I applied the change requested in ($gmane/235936), so there is no more comments left on that series, there's nothing that prevents that series from being picked, yet it's not. Presumably you have a problem with that series, but you haven't spoken, and you won't, even though it's not just me that is waiting for a response, but other Git developers (and users) who are interested in moving this forward. Anyway, I spent a lot of time working on those 160 patches, I would appreciate if you could respond to this single question: Are the patches going to be applied? Yes or no. -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-14 21:40 ` Felipe Contreras @ 2013-10-17 19:54 ` Junio C Hamano 2013-10-17 21:44 ` Felipe Contreras 0 siblings, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2013-10-17 19:54 UTC (permalink / raw) To: Felipe Contreras; +Cc: git Felipe Contreras <felipe.contreras@gmail.com> writes: > Junio C Hamano wrote: >> Such a review comment and the discussion that follows it after a >> patch is posted is an essential part of the collaborative >> development process in this community and it has helped the quality >> of our end product. We unfortunately saw time and again that the >> process rarely works when the discussion involves your patches. > > No, you did not. What you saw was a person that unlike a trained dog, argued > against you. And apparently your definition of a good discussion is one in > which the other person just does what you say, and doesn't argue back. That is so untrue that it is not even funny. If the ultimate goal of your whining is to spread misinformation to make you look like a victim, you are not worth talking to. Contributors often make sensible counter-arguments and/or explain the rationale better than they did in their original messages, and then receive a "Thanks for a dose of sanity" (or an equivalent phrased in different ways). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-17 19:54 ` Junio C Hamano @ 2013-10-17 21:44 ` Felipe Contreras 2013-10-18 11:21 ` Max Horn 0 siblings, 1 reply; 12+ messages in thread From: Felipe Contreras @ 2013-10-17 21:44 UTC (permalink / raw) To: Junio C Hamano, Felipe Contreras; +Cc: git Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > Junio C Hamano wrote: > >> Such a review comment and the discussion that follows it after a > >> patch is posted is an essential part of the collaborative > >> development process in this community and it has helped the quality > >> of our end product. We unfortunately saw time and again that the > >> process rarely works when the discussion involves your patches. > > > > No, you did not. What you saw was a person that unlike a trained dog, argued > > against you. And apparently your definition of a good discussion is one in > > which the other person just does what you say, and doesn't argue back. > > That is so untrue that it is not even funny. It is true, and there's penty of evidence that proves it. Every single time that you get mad at me, it's because I disagree with you. > Contributors often make sensible counter-arguments and/or explain > the rationale better than they did in their original messages, and > then receive a "Thanks for a dose of sanity" (or an equivalent > phrased in different ways). Yes, when there's an agreement, so you are basically proving what I said. I disagree with you, you disagree with me, and that means I'm the problem. In any healthy collaborative project that simply means there was a disagreement, and that's that. -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-17 21:44 ` Felipe Contreras @ 2013-10-18 11:21 ` Max Horn 2013-10-18 11:41 ` Felipe Contreras 0 siblings, 1 reply; 12+ messages in thread From: Max Horn @ 2013-10-18 11:21 UTC (permalink / raw) To: Felipe Contreras; +Cc: Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 4417 bytes --] 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. On 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote: > Junio C Hamano wrote: >> Felipe Contreras <felipe.contreras@gmail.com> writes: >> >>> Junio C Hamano wrote: >>>> Such a review comment and the discussion that follows it after a >>>> patch is posted is an essential part of the collaborative >>>> development process in this community and it has helped the quality >>>> of our end product. We unfortunately saw time and again that the >>>> process rarely works when the discussion involves your patches. >>> >>> No, you did not. What you saw was a person that unlike a trained dog, argued >>> against you. And apparently your definition of a good discussion is one in >>> which the other person just does what you say, and doesn't argue back. >> >> That is so untrue that it is not even funny. > > It is true, and there's penty of evidence that proves it. No, it is not true, and there is plenty of evidence that proves it. But 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. Of 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 ;-). (BTW, I am actually in favor of using the term "staging area" over "index") > Every single time that you get mad at me, it's because I disagree with you. I 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. > >> Contributors often make sensible counter-arguments and/or explain >> the rationale better than they did in their original messages, and >> then receive a "Thanks for a dose of sanity" (or an equivalent >> phrased in different ways). > > Yes, when there's an agreement, so you are basically proving what I said. I > disagree with you, you disagree with me, and that means I'm the problem. Actually, 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. > In any healthy collaborative project that simply means there was a > disagreement, and that's that. If 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... But 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. @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. Max [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-18 11:21 ` Max Horn @ 2013-10-18 11:41 ` Felipe Contreras 2013-10-18 15:30 ` Theodore Ts'o 0 siblings, 1 reply; 12+ messages in thread From: Felipe Contreras @ 2013-10-18 11:41 UTC (permalink / raw) To: Max Horn, Felipe Contreras; +Cc: Junio C Hamano, git Max Horn wrote: > 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. You should probably read the definition of troll: https://en.wikipedia.org/wiki/Troll_(Internet) Unless you think that contributing useful patches to Git is off-topic, a person that does that by definition cannot be a troll. > On 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote: > > Junio C Hamano wrote: > >> Felipe Contreras <felipe.contreras@gmail.com> writes: > >>> Junio C Hamano wrote: > >>>> Such a review comment and the discussion that follows it after a > >>>> patch is posted is an essential part of the collaborative > >>>> development process in this community and it has helped the quality > >>>> of our end product. We unfortunately saw time and again that the > >>>> process rarely works when the discussion involves your patches. > >>> > >>> No, you did not. What you saw was a person that unlike a trained dog, argued > >>> against you. And apparently your definition of a good discussion is one in > >>> which the other person just does what you say, and doesn't argue back. > >> > >> That is so untrue that it is not even funny. > > > > It is true, and there's penty of evidence that proves it. > > No, it is not true, and there is plenty of evidence that proves it. > > But 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. That's why I didn't bring it up. > And I hazard to guess that the vast majority agree with Junio on this (based, > again, on email evidence). Not with you. That is irrelevant, and a fallacy. The vast majority of people thought the Earth was the center of the universe, and they were all wrong. It's called ad populum fallacy, look it up. Wether the majority of Git developers agree that there's something more than a disagreement is irrelevant, their opinion doesn't change the truth. And by the way, a disregard for evidence is a clear sign of a person that is not interested in the truth. > Of 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. No, that's not what we are talking about. My claim is that all I did was disagree with Junio. You can invalidate that claim easily by providing *a single* example where I did more than disagree. > 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 ;-). I've stated multiple times that by "everybody" I mean "virtually everybody". Since Junio has accepted that "the index" is not the best term, "virtually everybody" is actually everybody that has voiced an opinion, except one single person. > > Every single time that you get mad at me, it's because I disagree with you. > > I 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. I can provide the evidence when Junio has become clearly "mad"... If you are interested in the truth that is. > 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. That is pure libel. Show me *one* example where I threw an insult, or "dirt". > >> Contributors often make sensible counter-arguments and/or explain > >> the rationale better than they did in their original messages, and > >> then receive a "Thanks for a dose of sanity" (or an equivalent > >> phrased in different ways). > > > > Yes, when there's an agreement, so you are basically proving what I said. I > > disagree with you, you disagree with me, and that means I'm the problem. > > Actually, it is more like this: "Felipe disagrees with Junio, Junio disagrees > with Felipe, Felipe insults Junio and in passing half a dozen other people." Lies. When did I insult anybody? > > In any healthy collaborative project that simply means there was a > > disagreement, and that's that. > > If your premise was correct (that there is simply a disagreement), then this > conclusion might be correct. As it is, though, your premise is false. Evidence, or that claim is dismissed. That which can be asserted without evidence can be dismissed without evidence. > The problem is rather a disruptive person: you. Nelson Mandela was considered a "disruptive person" (a terrorist[1]), yet virtually everyone agrees that the problem was not him, but the system that labeled him as such. [1] http://en.wikinews.org/wiki/Nelson_Mandela_taken_off_US_terrorist_list -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-18 11:41 ` Felipe Contreras @ 2013-10-18 15:30 ` Theodore Ts'o 2013-10-18 15:49 ` Felipe Contreras 2013-10-18 16:59 ` Junio C Hamano 0 siblings, 2 replies; 12+ messages in thread From: Theodore Ts'o @ 2013-10-18 15:30 UTC (permalink / raw) To: Felipe Contreras; +Cc: Max Horn, Junio C Hamano, git On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote: > > And I hazard to guess that the vast majority agree with Junio on this (based, > > again, on email evidence). Not with you. > > That is irrelevant, and a fallacy. The vast majority of people thought the > Earth was the center of the universe, and they were all wrong. > > It's called ad populum fallacy, look it up. Wether the majority of Git > developers agree that there's something more than a disagreement is irrelevant, > their opinion doesn't change the truth. Look, the problem is that you insist on being "right", even on matters which may be more about taste and preference than anything that can be proven mathematically. Worse, you insist on trying to convince people even when it might be better to just give up and decide that maybe something not's worth the effort to get the last word in. This is how we get to centithreads. If every time someone disagrees, you insist on replying, and then if people give up in disgust, you then try to use that as "proof" that you must be right, since you've dazzled them with your brilliance, that's not good for the development community. Sometimes a question is important enough that it's worth doing this. But I'd suggest to you that you should ask yourself whether you're doing it too often. After all, this is open source. If you are convinced that you are right, and everyone else in the community is wrong, it is within your power to fork the code base, and to prove us wrong by creating a better product. Or you can decide to just keep a patch set to yourself, or perhaps post it periodically, if it is some key feature that you are certain you or your company can't live with out. Heck, I've done this with ext4, even though I'm the maintainer --- there have been features that I know are critical for my company, but the rest of the ext4 development community are stridently against. I've just simply posted the patch set once, and if it gets strongly opposed, I'll just keep it as a out-of-tree patch. The fallocate NO_HIDE_STALE flag is a good example of that; it's used in production on thousands and thousands of servers by Google and Tao Bao, but since there was strong opposition on the ext4 list, we've kept it as an out-of-tree patch. Note what I did not do. I did not force the patch in, even though it might be within my power as the maintainer; nor did I try to convince people over and OVER and OVER again about the rightness of my position, and turn it into a centithread. > My claim is that all I did was disagree with Junio. You can invalidate that > claim easily by providing *a single* example where I did more than disagree. The problem is when you disagree with a number of people (not just Junio), and you are, in my opinion, overly persistent. We can argue whether you've stepped over the line in terms of impugning people's motives or sanity, but that's not necessarily the most important issue. People sometimes step over the line, and while that's unfortunate, it's when it becomes a persistent pattern, and it happens frequently enough, that it becomes a real problem. Alternatively, if you are right that Junio is mad, and he's being capriciously insulting, then I'm sure that when you establish your own fork, lots of developers will come flocking to your flag. If they do not, then perhaps you might want to take that as some objective evidence that the community is perhaps, more willing to work with him, then they are to work with you. Best regards, - Ted P.S. There are plenty of things that I consider to be unfortunate about git's command line interface, in terms of inconsistencies and confusing terminology. Over the past 5+ years, I've observed that I think the way commit selection in "git format-patch" is inconsistent with how we handle commit selection for other commands, e.g., "git log <commit>" vs and "git format-patch <commit>". Even if you think that this is a matter of self-inherent "truth", versus just a matter of taste, there is also the consideration of backwards compatibility, and the question of how important consistency and easy of learning gets traded off against backwards compatibility and invalidating potentially huge numbers of shell scripts and documentation. So it's not something where I've made a nuisance of myself, because it's a settled issue. As another example, people have agreed for a long time that the fact that tab characters are significant in Makefiles is highly unfortunate. However, no one is running around calling the GNU Make maintainers "insane" for not being willing to make a change that would break huge numbers of Makefiles in the world. More importantly, people aren't brining up the same subject over and over and over again on the GNU Makefile mailing list. Perhaps you might consider what would be the appropriate response if someone insisteted on creating centithreads on the GNU Makefile discuss list on that subject. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-18 15:30 ` Theodore Ts'o @ 2013-10-18 15:49 ` Felipe Contreras 2013-10-18 16:59 ` Junio C Hamano 1 sibling, 0 replies; 12+ messages in thread From: Felipe Contreras @ 2013-10-18 15:49 UTC (permalink / raw) To: Theodore Ts'o, Felipe Contreras; +Cc: Max Horn, Junio C Hamano, git Theodore Ts'o wrote: > On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote: > > > And I hazard to guess that the vast majority agree with Junio on this (based, > > > again, on email evidence). Not with you. > > > > That is irrelevant, and a fallacy. The vast majority of people thought the > > Earth was the center of the universe, and they were all wrong. > > > > It's called ad populum fallacy, look it up. Wether the majority of Git > > developers agree that there's something more than a disagreement is irrelevant, > > their opinion doesn't change the truth. > > Look, the problem is that you insist on being "right", even on matters which > may be more about taste and preference than anything that can be proven > mathematically. I don't insist on being right, I have an opinion and I voice it, there is nothing wrong with that. If the other side agrees there's a difference of opinion, that's the end of the discussion. I would say it's actually the other side that insists on being right, and that's the problem; they don't agree it's a difference in opinion, from their point of one side is right, and the other side is wrong, and that's what causes their frustration. Ask Junio if he thinks it's simply a matter of a difference in opinion. He pretty much already said it's not. > Worse, you insist on trying to convince people even when it might be better > to just give up and decide that maybe something not's worth the effort to get > the last word in. This is how we get to centithreads. If every time someone > disagrees, you insist on replying, This is how it goes: 1) Side A 2) Side B 3) Side A 4) Side B 5) Side A 6) Side B At any point in time side B could stop replying, sure, but so could side A. Why do you blame ME for replying, and not the other side, for replying to my reply? Presumably because right before reply 4), side A thought the discussion was wortwhile, and something happened in 5) that changed their opinion, and now side B becomes a problematic person. And since you are friends with side A, you take their side. > and then if people give up in disgust, you then try to use that as "proof" > that you must be right, Show me *one* instance when I have done so. I have never used silence as evidence of anything. > Sometimes a question is important enough that it's worth doing this. > But I'd suggest to you that you should ask yourself whether you're > doing it too often. > > After all, this is open source. If you are convinced that you are > right, and everyone else in the community is wrong, it is within your > power to fork the code base, and to prove us wrong by creating a > better product. Don't worry, that is *exactly* what I plan to do. > The fallocate NO_HIDE_STALE flag is a good example of that; it's used > in production on thousands and thousands of servers by Google and Tao > Bao, but since there was strong opposition on the ext4 list, we've > kept it as an out-of-tree patch. Note what I did not do. I did not > force the patch in, even though it might be within my power as the > maintainer; nor did I try to convince people over and OVER and OVER > again about the rightness of my position, and turn it into a > centithread. My patches are not good just for me or my company, they are good for everyone. Have you actually looked at any of them? > > My claim is that all I did was disagree with Junio. You can invalidate that > > claim easily by providing *a single* example where I did more than > > disagree. > > The problem is when you disagree with a number of people (not just > Junio), and you are, in my opinion, overly persistent. But that's not what Junio said. This is the second time you defend Junio by assuming his position is exactly the opposite. Junio doesn't think it's just a disagreement, Junio doesn't think I'm just being persistent, Junio is saying I can't be worked with. The interesting thing is that when Junio agrees with the change, he can work with me, when I agree my change is not good, the same, but suddenly when I don't agree, then I'm not good to work with. See the pattern? > We can argue whether you've stepped over the line in terms of impugning > people's motives or sanity, but that's not necessarily the most important > issue. People sometimes step over the line, and while that's unfortunate, > it's when it becomes a persistent pattern, and it happens frequently enough, > that it becomes a real problem. Have I ever impugned people's motives or sanity? Please, show me where I did that. > Alternatively, if you are right that Junio is mad, I didn't say Junio is mad, I said he got mad. : carried away by intense anger : furious <mad about the delay> http://www.merriam-webster.com/dictionary/mad > and he's being capriciously insulting, then I'm sure that when you establish > your own fork, lots of developers will come flocking to your flag. If they > do not, then perhaps you might want to take that as some objective evidence > that the community is perhaps, more willing to work with him, then they are > to work with you. If you know anything about rationality you know that correlation doesn't prove causation. So no, it would not be objective evidence. -- Felipe Contreras ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: My patches 2013-10-18 15:30 ` Theodore Ts'o 2013-10-18 15:49 ` Felipe Contreras @ 2013-10-18 16:59 ` Junio C Hamano 1 sibling, 0 replies; 12+ messages in thread From: Junio C Hamano @ 2013-10-18 16:59 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Felipe Contreras, Max Horn, git Theodore Ts'o <tytso@mit.edu> writes: > Over the past 5+ years, I've observed that I > think the way commit selection in "git format-patch" is inconsistent > with how we handle commit selection for other commands, e.g., "git log > <commit>" vs and "git format-patch <commit>". Even if you think that > this is a matter of self-inherent "truth", versus just a matter of > taste, there is also the consideration of backwards compatibility, and > the question of how important consistency and easy of learning gets > traded off against backwards compatibility and invalidating > potentially huge numbers of shell scripts and documentation. So it's > not something where I've made a nuisance of myself, because it's a > settled issue. The original syntax to select of commits by format-patch is very inconsistent from the log family because it was done way before the log family's way has been established as the best practice. It has annoyed enough people that we spent effort to teach recent Git to accept $ git format-patch master..next as well. So it indeed is a settled issue, but you are correct to point out that we had to find a way to do so while still keeping the original syntax working for people who have scripts and people who work from random and stale documents we have not much control over updating. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-10-18 16:59 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-10-12 7:24 My patches Felipe Contreras 2013-10-12 16:18 ` Philip Oakley 2013-10-12 22:33 ` Felipe Contreras 2013-10-14 17:42 ` Junio C Hamano 2013-10-14 21:40 ` Felipe Contreras 2013-10-17 19:54 ` Junio C Hamano 2013-10-17 21:44 ` Felipe Contreras 2013-10-18 11:21 ` Max Horn 2013-10-18 11:41 ` Felipe Contreras 2013-10-18 15:30 ` Theodore Ts'o 2013-10-18 15:49 ` Felipe Contreras 2013-10-18 16:59 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).