Re: My patches
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.contre...@gmail.com wrote: Junio C Hamano wrote: Felipe Contreras felipe.contre...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: My patches
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.contre...@gmail.com wrote: Junio C Hamano wrote: Felipe Contreras felipe.contre...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to
Re: My patches
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.
Re: My patches
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
Re: My patches
Theodore Ts'o ty...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My patches
Felipe Contreras felipe.contre...@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). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My patches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My patches
Felipe Contreras felipe.contre...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My patches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
My patches
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.contre...@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.contre...@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.contre...@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.contre...@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.contre...@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.contre...@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.contre...@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
Re: My patches
From: Felipe Contreras felipe.contre...@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 -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My patches
On Sat, Oct 12, 2013 at 11:18 AM, Philip Oakley philipoak...@iee.org wrote: From: Felipe Contreras felipe.contre...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
