Re: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Shouting your God is an imaginary shithead every time you see Mark There's no point in discussing with an unconstructive person as you. So go to a constructive person you call your friend and show him one of your calm rational mails and ask him for his opinion. Did you do so? Why not? Are you so infallible in communication that a second opinion from someone you trust would be irrelevant? Or is there nobody you trust? I've made my point, you are just talking nonsense. Every rational person on this list knows that if I wanted to, I could be much more offsensive and insulting. It would not appear that there any rational persons on this list apart from you. Not that it matters. I think that all the other irrational people on this list are rather more interested in your potential of being less offensive and insulting. Once the cure is worse than the ailment, namely you cause fewer work to be done on Git by your presence than you can do yourself, because of you distracting others and/or making them leave, it does not matter whether it could be even worse. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. The code quality of Git that many projects have come to trust their code with is much more than just the code at each moment keeps working for the users as long as the original author is around. The maintainer of a port to the platform X may lose access to the platform after switching jobs, the maintainer of a bridge to the foreign system Y may stop needing to talk to the foreign system after completing the switch to Git. Anybody can be hit by a bus, get sick, or simply lose interest in his past creations. By reading git log contrib/remote-helpers and comparing it with the logs for the rest of the system, you would realize that the former would not lead to a quality discussion similar to the one that led to [*2*], which was only possible because the change was adequately described to allow anybody to understand the original issue the change was meant to solve. The commit that made the original change made it easy to ask a critical question: You are improving B but at the same time breaking A. Can we do better to help both A and B? And it allowed us to move forward without having to rob Peter to pay Paul. Granted, these contrib/ patches were applied with the understanding that contrib/ stuff can be substandard, because having anything is often better than having nothing, and you cannot go back in time to update the history to make these commits more useful to others who will come later. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*], which is just one of the examples that illustrate that there clearly is no will to explain the changes to help others who come later to help maintaining the code. I'll take good care of the codebase, I've spend the time to make it better, Me, me, me, is not what the open source process is about. Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. Neglate one or the other, and sooner or later people will refuse to collaborate with you, because it's just too much work to deal with the downsides. My hope is that for future events of this nature to be detected sooner and dealt with more rigidly, e.g by making it clear this or that behavior is not acceptable. I think part of the problem here is that we let the situation install itself, by accepting B-side issues just because A-side was ok, hopeful that B-side would solve itself. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. Of course I am a major proponent of this view because of being myself somewhat differently endowed in the respective classes A and B, and so having at least some sort of exchange rate between the two can, however large the conversion fees, only benefit me... -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. I think this only means that you can get away with B issues if A's quality is very very very high, which doens't happen very often. And I doubt that you will be able to get away with it for long anyway, at some point some mechanism will be put in place so the downsides of B aren't visible to everyone... for example with the patches being sent to one person only and this person relays it to the list while filtering B's issues. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. I think this only means that you can get away with B issues if A's quality is very very very high, which doens't happen very often. I would not exactly say get away with B issues. It's like saying you can get away with looking like a sleazebag if you plan the time for a complete border search whenever traveling abroad. Of course that means that traveling into countries where complete border search might entail depriving you of your civic rights and locking you up for decades in a torture camp without due process is plainly not an option. But if you are honest: everybody has to be prepared for that. It's just less likely to occur in practice. Basically you have to write in a manner if a seedy stranger gave me that code on a street corner, I would have no problem checking it in. In practice, the shortcuts offering themselves through civil behavior and mutual trust get a lot more work done. But they _are_ a vector for social engineering. You have to admit that it seems pretty unlikely by now that Felipe is trying to sneak in some NSA-written code without arousing people's suspicions. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
Basically you have to write in a manner if a seedy stranger gave me that code on a street corner, I would have no problem checking it in. In practice, the shortcuts offering themselves through civil behavior and mutual trust get a lot more work done. My point was more that it's very hard to produce high quality commits without social interaction with others explaining what you missed, stuffs you overlooked, etc. And there B issues quickly isolate you. You have to admit that it seems pretty unlikely by now that Felipe is trying to sneak in some NSA-written code without arousing people's suspicions. Not sure where I implied otherwise... and the earlier metaphore about country borders doesn't make much sense to me. Anyway, I think we are speaking about different things. All I'm saying is that humans are social creatures and that thinking you can contribute to projects ran by humans without according a high importance to social behaviors (like Felipe thinks) is not possible. Threads like this are proof that while technical quality might be important for the short term, social behaviors is impossible to ignore in the long term. Both are very important to be an appreciated contributor, or to contribute at all in the long term. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: Basically you have to write in a manner if a seedy stranger gave me that code on a street corner, I would have no problem checking it in. In practice, the shortcuts offering themselves through civil behavior and mutual trust get a lot more work done. My point was more that it's very hard to produce high quality commits without social interaction with others explaining what you missed, stuffs you overlooked, etc. You are overgeneralizing. You are assuming that it's easier for everybody to interact with humans rather than the Tao of Computing. And there B issues quickly isolate you. Unless you were isolated to start with. Anyway, I think we are speaking about different things. All I'm saying is that humans are social creatures and that thinking you can contribute to projects ran by humans without according a high importance to social behaviors (like Felipe thinks) is not possible. You are assuming that according a high importance to social behaviors is all that it takes for anybody. Do you tell the beggar on the next street corner that according a high importance to earning millions would be all that would be necessary for him to afford anything to drink that he'd like? Threads like this are proof that while technical quality might be important for the short term, social behaviors is impossible to ignore in the long term. Not really. Both are very important to be an appreciated contributor, or to contribute at all in the long term. The one thing where social behavior comes in is noticing who tends to be running free software projects. There is the mythical scratching one's itch theory, but it does not fit the bill. Those people who invest enough time into a project's progress to make a fundamental difference tend to do it at the cost of not having any worthwhile amount of time left actually _using_ the product. People mainly working on music software create very little music themselves, people mainly working on text processing software do not write many texts themselves, people writing high-performance operating systems have very little use for high-performance operating systems themselves. All of this might have started at one time as scratching their own itch, but once their contributions become significant, it's almost always the itches of others they are scratching, and continue to scratch, feeling responsible for them due to the skills they have been not as much blessed or cursed but entrusted with. And programming and social skills tend to be packaged separately. So not everybody is gifted with being able to contribute _gracefully_. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
My point was more that it's very hard to produce high quality commits without social interaction with others explaining what you missed, stuffs you overlooked, etc. You are overgeneralizing. You are assuming that it's easier for everybody to interact with humans rather than the Tao of Computing. No, what I'm saying is that most non-trivial patches go through a review process involving human interactions. It is very hard to produce a very good non-trivial patch without going through human interactions, just because someone might ask a question about your patch. To be honest I'm not interested in fighting over this so let's agree to disagree. Anyway, I think we are speaking about different things. All I'm saying is that humans are social creatures and that thinking you can contribute to projects ran by humans without according a high importance to social behaviors (like Felipe thinks) is not possible. You are assuming that according a high importance to social behaviors is all that it takes for anybody. Do you tell the beggar on the next street corner that according a high importance to earning millions would be all that would be necessary for him to afford anything to drink that he'd like? I'm sorry that my words aren't clear enough for you to infer the point I'm trying to make. Let's try something simpler: what I was saying is that bad behavior will get you into trouble when contributing (and thus it's important to behave nicely), where Felipe usualy says bad behavior is irrelevant because only truth/quality is important. And programming and social skills tend to be packaged separately. So not everybody is gifted with being able to contribute _gracefully_. Yes it's unfortunate. The amount of talent in our societies that is wasted because of communication problems is probably quite high. I didn't find a way around being social in any human based community yet, but if you have an idea please share. The only way I can see working is that for someone to act as a mediator between the grumpy contributor and the community, but the role of this person is not very pleasant. That or maybe have merges done by some kind of robot with some AI about patch quality, but I doubt it is technically feasible yet. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: I'm sorry that my words aren't clear enough for you to infer the point I'm trying to make. Let's try something simpler: what I was saying is that bad behavior will get you into trouble when contributing (and thus it's important to behave nicely), where Felipe usualy says bad behavior is irrelevant because only truth/quality is important. Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? Yes it's unfortunate. The amount of talent in our societies that is wasted because of communication problems is probably quite high. I didn't find a way around being social in any human based community yet, but if you have an idea please share. being social as an isolated feat is self-contradictory. The question is how to function in a particular social context. Stock answers apply to stock behaviors and are obviously most efficient to apply. Yesterday my girl friend bought back a mare she had sold two years ago because its owner did not manage to get along with it. It's a temperamental animal that learns and performs amazingly well for its comparatively compact build. But it's highest in rank or else, and so in the end it got locked up in its stable box most of the time in order to avoid injuries to other horses. Now it's back here at the riding school, and there is little question that there will be some injuries before things settle down again even though most of the horses here know it already. The only way I can see working is that for someone to act as a mediator between the grumpy contributor and the community, but the role of this person is not very pleasant. That or maybe have merges done by some kind of robot with some AI about patch quality, but I doubt it is technically feasible yet. Well, humans are more complex. There are no sure-fire recipes even for working with horses: some of them here have their separate paddocks because things would not settle down, some of them have standard conflicts, there are occasional injuries. The most important standard recipe is to make sure that the areas accessible to multiple horses do not have dead ends small enough for one horse to be able to corner another. That's not really fabulous but still pretty essential. Also enough room all around, obviously. Now humans are often held in conditions that are not species-appropriate and lead to a buildup of tension. Try finding an undisturbed spot in a typical city suitable for devouring a bread roll you hunted down without getting other predators eyeing your prey. Almost impossible. It may be that distributed version control systems offer more possibilities for organizing cooperation in a manner leaving graceful escape paths when things don't work out. It's not what one want to have to rely on permanently but it may be worth thinking about ways to make consequences from difficulties less inevitable and/or grave. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
I'm sorry that my words aren't clear enough for you to infer the point I'm trying to make. Let's try something simpler: what I was saying is that bad behavior will get you into trouble when contributing (and thus it's important to behave nicely), where Felipe usualy says bad behavior is irrelevant because only truth/quality is important. Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), and I feel that I am pretty much in control of my reactions given I am able to not give in to the burst of emotions that some of his behavior can trigger. For the record I'm not really blaming Felipe for what he does, I'm saying a solution has to be found to prevent his behavior from harming people, and that a solution that involves everyone adapting to Felipe is not reasonable. Yesterday my girl friend bought back a mare she had sold two years ago because its owner did not manage to get along with it. It's a temperamental animal that learns and performs amazingly well for its comparatively compact build. But it's highest in rank or else, and so in the end it got locked up in its stable box most of the time in order to avoid injuries to other horses. Now it's back here at the riding school, and there is little question that there will be some injuries before things settle down again even though most of the horses here know it already. I think that is the point: behave properly or be isolated to avoid harming others. Wether you control your behavior or not has little to do with it, it's your behavior that counts. That's how it works in pretty much any communities I know of. It may be that distributed version control systems offer more possibilities for organizing cooperation in a manner leaving graceful escape paths when things don't work out. It's not what one want to have to rely on permanently but it may be worth thinking about ways to make consequences from difficulties less inevitable and/or grave. Sure, I believe my proposal of acting on bad behavior earlier would prevent incidents like this one, because it would defuse situations before they settle in. But that's just a proposal, I'm just an observer here. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher wrote: I'm sorry that my words aren't clear enough for you to infer the point I'm trying to make. Let's try something simpler: what I was saying is that bad behavior will get you into trouble when contributing (and thus it's important to behave nicely), where Felipe usualy says bad behavior is irrelevant because only truth/quality is important. Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), I am pretty much in control of my behavior. Those who know me personally know that I *never* get angry. The problem is that what you label as bad behavior I do not. For example the atheist billboard that said You KNOW it's a Myth. This Season, Celebrate REASON! caused a lot of furor, and people all over U.S.A. said you cannot say that!, that's offensive!, it's a war against Christmass, that shouldn't be tolerated in modern society, and so on. Of course, it should be tolerated in a modern society, and it should not be offensive, those are facts. Of course people can disagree with those facts (but those people are wrong). The atheists are not engaging in bad behavior, it's just that the majority constituted by religious and bend-over-backwards-liberals have a different definition of bad behavior (a wrong definition). So if somebody convinced me that my behavior is indeed bad, I would certainly change it, but I do not think it's bad. Just the same way nobody has convinced many atheists that their behavior in those billboards is bad. And they can't convince them, because they would need logic, reason, and evidence, and the atheists have them. Yesterday my girl friend bought back a mare she had sold two years ago because its owner did not manage to get along with it. It's a temperamental animal that learns and performs amazingly well for its comparatively compact build. But it's highest in rank or else, and so in the end it got locked up in its stable box most of the time in order to avoid injuries to other horses. Now it's back here at the riding school, and there is little question that there will be some injuries before things settle down again even though most of the horses here know it already. I think that is the point: behave properly or be isolated to avoid harming others. Wether you control your behavior or not has little to do with it, it's your behavior that counts. That's how it works in pretty much any communities I know of. Except the largest and most important communities; countries. In the vast majority of countries what is labeled as bad (a.k.a. illegal) has had much more consideration (millenia) than in most online communities (barely decades). Saying something is stupid might be considered bad to some people, but not all, so you can't get thrown in jail for doing that, even though some peple thing it's harming others. For example, saying religion is stupid. In order to be thrown in jail you have to do something _truly_ bad, something we all agree is harming others. In online communities facts don't matter, if the majority thinks you are doing something bad (even if you are not), you get thrown to jail (or virtual jail). It may be that distributed version control systems offer more possibilities for organizing cooperation in a manner leaving graceful escape paths when things don't work out. It's not what one want to have to rely on permanently but it may be worth thinking about ways to make consequences from difficulties less inevitable and/or grave. Sure, I believe my proposal of acting on bad behavior earlier would prevent incidents like this one, because it would defuse situations before they settle in. But that's just a proposal, I'm just an observer here. What you label bad behavior started *because* of Junio's decision. Junio made an important (to me) decision based on a *TECHNICAL* reason he never explained. My bad behavior basically consisted in pointing out Junio's bad behavior. In this case I'm not very dissimilar to Edward Snowden. Snowden did somethig bad in the eyes of many people, but he did it *because* of something deeper and more important. It was the government that caused Snowden's actions, and it is the government's bad behavior that is important. But if you look at the mass media, they don't concentrate on the government's actions (that's risky), they concentrate on Snowden. This might have changed after Snowden gained support, but at least initially it was this way. You are doing exactly the same as the mass media. Instead of looking at the actions of Junio, namely his *TECHNICAL* decision which *triggered* my bad behavior, you look at me, the easy target, and ignore the real problem. Wait, wait! Before focusing on deciding whether leaking documents is bad, and how exactly it was carried out, why don't you concentrate on the real issue; the fact
Re: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Philippe Vaucher wrote: [...] Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), I am pretty much in control of my behavior. Those who know me personally know that I *never* get angry. You are missing the point. The point is not what effect your behavior has on you but what it has on others. As you are unable to attribute feelings to others (like you appear unable to attribute reason to them), you are unable to control it. It's like repairing clockwork when your hands are numb and have never been otherwise. When something does not work, apply extra force does not work with clockwork. It does not work with people, either. The problem is that what you label as bad behavior I do not. It does not matter what you or others want to label it. The effects are there anyway. So if somebody convinced me that my behavior is indeed bad, I would certainly change it, but I do not think it's bad. What effect your behavior has on others is not dependent on what you think about it. If you convinced yourself to be standing perfectly balanced and find yourself falling, there is no point in not catching yourself before smashing your head open just because you _know_ you have been standing perfectly upright. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: Philippe Vaucher wrote: [...] Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), I am pretty much in control of my behavior. Those who know me personally know that I *never* get angry. You are missing the point. The point is not what effect your behavior has on you but what it has on others. If me saying I do not believe in God has a negative effect on Mark, your answer seems to be do not tell Mark the truth. If Mark was a co-worker and I had no option but to interact with him, I would probably do something along those lines if possible. But if Mark was a member of an open source project, I do have an option and I'd rather tell it like it is. If Mark has a problem with that, I can always avoid Mark, or just leave the project (say if Mark was the maintainer). In both cases Mark is wrong. I do understand that most people would rather comprimise their beliefs in order to win penguing points. I'm not that way. If I can't speak my mind in an open source project where I'm contributing my time *for free*, I do not want to be part of that project. It's the project that's wrong, not me, and it's the project that looses, not me. -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: Philippe Vaucher wrote: [...] Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? I feel that Felipe cannot control this (or decided not to), I am pretty much in control of my behavior. Those who know me personally know that I *never* get angry. You are missing the point. The point is not what effect your behavior has on you but what it has on others. If me saying I do not believe in God has a negative effect on Mark, your answer seems to be do not tell Mark the truth. Shouting your God is an imaginary shithead every time you see Mark and asking everybody in the room Isn't it right that Mark's God is an imaginary shithead? Can anybody here testify having seen him? whenever anybody is there, and occasionally calling him and others on the phone when you have nothing else to do and tell him that you consider his God an imaginary shithead and him a gullible fool to believe otherwise... Do you really think that's the way you are going to earn people's respect? By prouding yourself on having seen through Mark's purported stupidity and pointing it out to everybody? But if Mark was a member of an open source project, I do have an option and I'd rather tell it like it is. And everybody else, of course, is wrong about it. And only you are right. All you need to do is to be as obnoxious as you can manage, and you'll win everyone over to your side. Don't kid yourself: you are doing this entire sad spectacle only to satisfy your own self-righteousness, just to be able to tell yourself all those people working on Git with the exception of myself are pitiable fools and/or bad persons letting Junio pull the wool over their eyes. You've made your point. People don't agree with it. Repeating your point over and over will not change that. If Mark has a problem with that, I can always avoid Mark, or just leave the project (say if Mark was the maintainer). In both cases Mark is wrong. I do understand that most people would rather comprimise their beliefs in order to win penguing points. I'm not that way. No, you rather compromise your standing in order to win your beliefs. Take them. They are yours. Nobody else wants them. Even if there would have been merit in them originally, after revomiting them a dozen times on people's laps they just want the stench to go away. If I can't speak my mind in an open source project where I'm contributing my time *for free*, I do not want to be part of that project. It's the project that's wrong, not me, and it's the project that looses, not me. Well, you are a sore winner for sure. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
David Kastrup d...@gnu.org writes: Philippe Vaucher philippe.vauc...@gmail.com writes: Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. I would have to say that you are living in a fantasy land. During the entire life of Git, I do not think I ever saw such a code that is perfect from the get-go and did not require any maintenance to adjust to the changing time. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: Philippe Vaucher philippe.vauc...@gmail.com writes: Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way respond constructively), which we discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. I would have to say that you are living in a fantasy land. During the entire life of Git, I do not think I ever saw such a code that is perfect from the get-go and did not require any maintenance to adjust to the changing time. You are attacking a straw man. where the original author could not offer significant _additional_ help does not at all equate does not require any maintenance. -- David Kastrup -- 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: [PATCH 0/4] remote-hg: more improvements
David Kastrup d...@gnu.org writes: I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. I would have to say that you are living in a fantasy land. During the entire life of Git, I do not think I ever saw such a code that is perfect from the get-go and did not require any maintenance to adjust to the changing time. You are attacking a straw man. where the original author could not offer significant _additional_ help does not at all equate does not require any maintenance. Ahh, I realize that I misread what you wrote. Yes, I do agree with you that we have a lot of pieces of code, with log messages we can find with the help of blame, that the author himself does not need to be present for them to be maintained properly. Making all the code in Git like that may be an unattainable goal, but calling the effort to make that happen living in a fantasy land is utterly wrong. Sorry about confusion. -- 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: [PATCH 0/4] remote-hg: more improvements
David Kastrup wrote: Shouting your God is an imaginary shithead every time you see Mark There's no point in discussing with an unconstructive person as you. I've made my point, you are just talking nonsense. Every rational person on this list knows that if I wanted to, I could be much more offsensive and insulting. -- 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: [PATCH 0/4] remote-hg: more improvements
Nevermind, it'd be more efficient to cover this in the other main thread started by Felipe. You can answer my questions there instead as it'll likely benefit a wider audience. Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. The code quality of Git that many projects have come to trust their code with is much more than just the code at each moment keeps working for the users as long as the original author is around. The maintainer of a port to the platform X may lose access to the platform after switching jobs, the maintainer of a bridge to the foreign system Y may stop needing to talk to the foreign system after completing the switch to Git. Anybody can be hit by a bus, get sick, or simply lose interest in his past creations. By reading git log contrib/remote-helpers and comparing it with the logs for the rest of the system, you would realize that the former would not lead to a quality discussion similar to the one that led to [*2*], which was only possible because the change was adequately described to allow anybody to understand the original issue the change was meant to solve. The commit that made the original change made it easy to ask a critical question: You are improving B but at the same time breaking A. Can we do better to help both A and B? And it allowed us to move forward without having to rob Peter to pay Paul. Granted, these contrib/ patches were applied with the understanding that contrib/ stuff can be substandard, because having anything is often better than having nothing, and you cannot go back in time to update the history to make these commits more useful to others who will come later. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*], which is just one of the examples that illustrate that there clearly is no will to explain the changes to help others who come later to help maintaining the code. I'll take good care of the codebase, I've spend the time to make it better, Me, me, me, is not what the open source process is about. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 *2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204 -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*] [1] happened *AFTER* you made that stupid decision. Don't make it look as if your decision was caused by [1], *YOU* caused [1]. If you want to show that the quality of the commit messages or the code caused that decision, show an issue in that respect that happened *BEFORE* your decision. It is very clear what is happening. Junio made a wrong decision based a non-issue, then it became abudantly clear that there was no basis for such decision, this why he never clarified the reasoning behind. Then, *AFTER* I reacted to his decision he grabbed that opportunity to say no, look, this _new_ thing Felipe is doing is the reason. Nice try. If the behavior in [1] is the reason, the solution is easy; I'll revert back to my old behavior where I explained everything in detail, and updated the commit messages if something wasn't clear. I would: 1. Make sure the regression is fixed Git v2.0 2. Send a clarified patch for the hg 3.0 compatibility 3. Look for other important patches that might be missing and provide all the details why they are important 4. Rebase and clean the rest of the patches to make sure nothing is missing This is what I was going to do anyway *BEFORE* you made that decision. And this commitment to quality is what I've been doing since day one. *YOU* changed that by throwing away all my hard work. If the issue was truly the behavior in [1], the outline above should get rid of the (fake) problem you mention. We make a compromise, you ignore this temporary bump (that *you* caused), and I go back to high quality standards (which I was already doing anyway before). The graduation process continues, and *IF* another instance like [1] comes (it won't), then the graduation process is canceled. Ignoring temporary set-backs, finding common ground, and making an agreement on future behavior is in the best interest of our users. Will you do it? *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: ... I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. I think you misunderstood. I never said that I do not want it to graduate up (out is an option) based on code quality. In fact, I do not think anybody discussed about code quality until this morning. But because I was asked, I thought about it, and then answered honestly. I do not know what a trap you perceive is about, and I am not interested in your responses. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: ... I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. I think you misunderstood. I never said that I do not want it to graduate up (out is an option) based on code quality. Fair enough, that was my understanding up until today. But because I was asked, I thought about it, and then answered honestly. I do not know what a trap you perceive is about, and I am not interested in your responses. Philippe Vaucher didn't ask about quality, he asked about moving out of contrib. -- 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: [PATCH 0/4] remote-hg: more improvements
I addressed every issue reported constructively, every bug report was fixed, every patch reviewed and usually improved by me. I made sure users of older versions wouldn't be affected negatively when the marks file was upgraded, and I even setup automatic tests for different versions Bazaar and Mercurial that run every time I push to my repository. It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If git-remote-hg belongs in the contrib area, so does git-svn, and git-p4. Here too, can you clarify a bit about what should be out of tree and what should be in contrib? I understand that not all rules are set in stone and that there is an historical baggage for which applying all rules is probably more trouble than it's worth, but again it's nice to clarify for future users. Also it'd probably be worth commenting on unwritten rules about human factors (easyness of communication, response to criticisim, ability to make concessions, etc). Philippe -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: I already said this multiple times, but let me be clear once more: MASTER HAS A REGRESSION (for all versions of Mercurial). As you said, that is not a regression, isn't it? It is an old breakage that existed even before 1.9 (was it 1.8.3 or something?) No. It does't happen in 1.9, it will happen in 2.0. That's a REGRESSION. You earlier said in our exchange: Wrong. The code in question was not recent, it was introdued in 1.8.3, more than one year ago. and git blame -L870,880 contrib/remote-helpers/git-remote-hg does show that 68d4f4f3 (remote-hg: custom method to write tags, 2013-04-22) is the culplit that has introduced ManifestLookupError. And it is in since 1.8.3. How does it break 2.0 and without breaking 1.9? The dormant and otherwise unused code got its first caller, or something? If this were a core part of the system the only sensible thing we can do at this point is to revert at this late stage of the cycle, but I do not think I have time to bisect and find that culprit, as today is when -rc3 has been scheduled to happen. -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: There may be some other changes that this series depends on that I may have missed that caused this breakage. Can you take a look? I'm such a bad maintainer and I don't take constructive criticism well why would you expect me to take a look? Because this was not about maintainership, but was a simple and straight-forward breakage report [*1*]. There was no criticism involved, constructive or otherwise. In other words, I knew that you are capable enough to track down a bug in the code you wrote recently that made it violate the expectation you defined in your own tests. There was no room for differences of opinions to come into play, as it was just between you and your own code. Why would I expect otherwise? Do you want to make it a separate follow-up patch with a log message that explains why it now uses LookupError (not ManifestLookupError), or do you want to reroll the original by squashing it? I am guessing that the reason is because in older versions they used LookupError but in recent versions ManifestLookupError which is a subclass is thrown instead, and catching the former would cover both cases, so if I were to queue it as a separate [PATCH 5/4] fixup, that is how I would explain that change. [Footnote] *1* and a very bad one at that, missing any useful details; I apologize and blame lack of time for its lousiness. Thanks for working with very little useful information and fixing. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: In other words, I knew that you are capable enough to track down a bug in the code you wrote recently that made it violate the expectation you defined in your own tests. Wrong. The code in question was not recent, it was introdued in 1.8.3, more than one year ago. And wrong, it didn't violate the expectation of my own tests. The code was simply not exercised in the tests. There was no room for differences of opinions to come into play, as it was just between you and your own code. Why would I expect otherwise? Because most people take attacks on their code as personal attacks, and they don't fix bugs in their code if they don't like the person reporting it. But you know I don't take attacks on my code and ideas personally, which is more that can be said of most people on the list. Do you want to make it a separate follow-up patch with a log message that explains why it now uses LookupError (not ManifestLookupError), or do you want to reroll the original by squashing it? I don't want to do anything for a contrib tool. It's already broken in v2.0 anyway. -- 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: [PATCH 0/4] remote-hg: more improvements
James Denholm wrote: Felipe, I would ask, suggest, beg, implore you to calm down. I am calmed down. I waited a day before replying to make sure of that. It's generally not a good plan to alienate the maintainer of a project, regardless of the correctness or incorrectness of one's arguments, but I fear that's only what you will achieve at the moment. He has already alienated me. In fact he asked me before to leave the mailing list. And I did for a while. However, at some level he knows my patches are beneficial to the project, so he is applying them again. Either way it doesn't matter if I'm calmed down or not, abrassive or civil, this ad hominmen double standards bullshit is going to continue. See what was his reply to my mail? *Nothing*. What was his reply when I argued if he even admitted he could potentially be wrong, and if so would essentially trash a project I've worked very hard for? *Nothing*. What was his reply when I argued that git-remote-hg has more quality than all the tools in contrib, even some in the core and therefore doesn't belong there? *Nothing*. What was his reply when I said double standards were applied for git-remote-hg. *Nothing*. How about when I argued there was no mechanism for out-of-tree tools to be properly maintained and promoted, and moving tools outside of the tree shouldn't be done before that happens? *Nothing*. What did he say when I suggested to move out git-p4 and git-svn, if he is so sure important tools can flourish out-of-tree? *Nothing*. The truth is that it doesn't matter how I present my arguments, calmly or otherwise. He is *never* going to accept he was wrong, especially not when that would mean I was right. Don't expect any more git-remote-hg patches from me. If Junio thinks it's just another crappy contrib tool, then I'll threat it as one. And unfortunately Junio would rather let an important part of Git die a slow death rather than admit he was wrong. Just watch him ignore the problem. -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: In other words, I knew that you are capable enough to track down a bug in the code you wrote recently that made it violate the expectation you defined in your own tests. Wrong. The code in question was not recent, it was introdued in 1.8.3, more than one year ago. And wrong, it didn't violate the expectation of my own tests. The code was simply not exercised in the tests. There was no room for differences of opinions to come into play, as it was just between you and your own code. OK, I misread the blame output---sorry about that. But that does not change the fact that your tests caught a bug in your own code, and the issue was solely between you and your own code without involving criticism from anybody, does it? Unless you count a barf from a rather old version of Mercurial as a criticism, that is. Why would I expect otherwise? Because most people take attacks on their code as personal attacks, and they don't fix bugs in their code if they don't like the person reporting it. But you know I don't take attacks on my code and ideas personally, which is more that can be said of most people on the list. Just to make sure new people who may be watching with popcorns in their hand from sidelines do not get a wrong impression, I do not share your most people take attacks ... observation. In reviews I have seen over the years around here (and also reviews at $DAYJOB), I rarely saw such a reaction by the person whose change is reviewed. I view this list as very cooperative and productive environment most of the time. In any case, there was not even any attack---it was merely your code not passing your own test on a platform you did not have access to, which is not something to be upset about. I don't want to do anything for a contrib tool. It's already broken in v2.0 anyway. Yes, this is not even an old regression. If you no longer want to have it in contrib/, I can drop it in future releases (but not in v2.0), so that people can find the latest and greatest directly from you. Otherwise, queuing a fix on 'pu' and then to 'next' in preparation for an early graduation for the release after v2.0 (and as a fix, it may want to go to older maintenance releases) is also fine by 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: I don't want to do anything for a contrib tool. It's already broken in v2.0 anyway. Yes, this is not even an old regression. Yes it is. It has nothing to do with with Mercurial v3.0, that's a separate issue. We've been doing a workaround since v1.8.3, and that workaround will break things in v2.0. I already said this multiple times, but let me be clear once more: MASTER HAS A REGRESSION (for all versions of Mercurial). If you no longer want to have it in contrib/, I can drop it in future releases (but not in v2.0), so that people can find the latest and greatest directly from you. Otherwise, queuing a fix on 'pu' and then to 'next' in preparation for an early graduation for the release after v2.0 (and as a fix, it may want to go to older maintenance releases) is also fine by me. Are you saying that the graduation plan is going to continue and they are going to move out of contrib and be distributed by default? If that's the case I'll resume the fixes because the current sitution is not good. -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: I already said this multiple times, but let me be clear once more: MASTER HAS A REGRESSION (for all versions of Mercurial). As you said, that is not a regression, isn't it? It is an old breakage that existed even before 1.9 (was it 1.8.3 or something?) If you no longer want to have it in contrib/, I can drop it in future releases (but not in v2.0), so that people can find the latest and greatest directly from you. Otherwise, queuing a fix on 'pu' and then to 'next' in preparation for an early graduation for the release after v2.0 (and as a fix, it may want to go to older maintenance releases) is also fine by me. Are you saying that the graduation plan is going to continue and they are going to move out of contrib and be distributed by default? I do not think that is going to happen. As we discussed already, I do see merit in unbundling it from my tree. I can keep it in contrib/ as that is a slight benefit for you (i.e. you can be lock-step with Git) but as long as you live in my tree, you need to follow the same release schedule as the other contributors, which may be detrimental to your users, compared to a case where it is unbundled. I do not see a strong reason to move it out of contrib, either. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: I already said this multiple times, but let me be clear once more: MASTER HAS A REGRESSION (for all versions of Mercurial). As you said, that is not a regression, isn't it? It is an old breakage that existed even before 1.9 (was it 1.8.3 or something?) No. It does't happen in 1.9, it will happen in 2.0. That's a REGRESSION. If you no longer want to have it in contrib/, I can drop it in future releases (but not in v2.0), so that people can find the latest and greatest directly from you. Otherwise, queuing a fix on 'pu' and then to 'next' in preparation for an early graduation for the release after v2.0 (and as a fix, it may want to go to older maintenance releases) is also fine by me. Are you saying that the graduation plan is going to continue and they are going to move out of contrib and be distributed by default? I do not think that is going to happen. Then I don't understand what you mean by graduation. As we discussed already, I do see merit in unbundling it from my tree. You are blind. Move git-p4 and git-svn out of your tree. You know what will happen. I can keep it in contrib/ as that is a slight benefit for you What is the benefit of being in contrib/? Even you yourself argued that there is not much point of 'contrib/' nowadays[1]. The only reason we might want something in contrib/ is so that it has a chance to mature before becoming part of the core. (i.e. you can be lock-step with Git) but as long as you live in my tree, you need to follow the same release schedule as the other contributors, which may be detrimental to your users, compared to a case where it is unbundled. It's much more beneficial to *our* users if these tools are distributed by default. I do not see a strong reason to move it out of contrib, either. Really? So why did you say this?[2] Either way, I think if things go well, remote-hg will prove it's worth and move out of contrib and into git's core. That was what you promised when we started carrying it in contrib/; I am still hoping to see it happen when it matures. Jeff said the same thing when he was acting as maintainer[3], and you didn't correct him: I would one day like to have it as part of the main distribution, too, but it would be nice to prove its worth in the field for a while first. All this time I've been operating under the impression that once git-remote-hg proved itself, it would graduate out of contrib. So basically you tricked me, and I wasted insane amounts of time chasing a target that was impossible to reach. Fuck this. [1] http://article.gmane.org/gmane.comp.version-control.git/220178 [2] http://article.gmane.org/gmane.comp.version-control.git/220277 [3] http://article.gmane.org/gmane.comp.version-control.git/208648 -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Here's a bunch of tests more, and a fixes for Mercurial v3.0. I think the discussion with John Keeping hints that we shouldn't be rushing fc/remote-helpers-hg-bzr-graduation and this does not appear to assume the presense of that series, which is good in order to make these fixes jump over them. I'll queue this separately on a topic based on the tip of yesterday's master for now. One thing I couldn't read from the proposed log messages was if this is meant to work with and tested with both v3.0 and pre-v3.0 Hg, or this is to request others who run pre-v3.0 Hg to test these changes. For example, I see from mercurial import changegroup if check_version(3, 0): cg = changegroup.getbundle(...) else: cg = repo.getbundle(...) and offhand it was unclear if the unconditional import was a mistake. Thanks. Felipe Contreras (4): remote-hg: add more tests t: remote-hg: add file operation tests t: remote-hg: trivial cleanups and fixes remote-hg: add support for hg v3.0 contrib/remote-helpers/git-remote-hg | 6 +- contrib/remote-helpers/test-hg.sh| 240 ++- 2 files changed, 238 insertions(+), 8 deletions(-) -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Here's a bunch of tests more, and a fixes for Mercurial v3.0. I think the discussion with John Keeping hints that we shouldn't be rushing fc/remote-helpers-hg-bzr-graduation Really? Based on what reasoning? I have proven his reasoning to be basically wrong. I'll queue this separately on a topic based on the tip of yesterday's master for now. One thing I couldn't read from the proposed log messages was if this is meant to work with and tested with both v3.0 and pre-v3.0 Hg, or this is to request others who run pre-v3.0 Hg to test these changes. For example, I see from mercurial import changegroup if check_version(3, 0): cg = changegroup.getbundle(...) else: cg = repo.getbundle(...) and offhand it was unclear if the unconditional import was a mistake. Of course it wasn't a mistake. -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Here's a bunch of tests more, and a fixes for Mercurial v3.0. I think the discussion with John Keeping hints that we shouldn't be rushing fc/remote-helpers-hg-bzr-graduation Really? Based on what reasoning? I have proven his reasoning to be basically wrong. Perhaps s/proven/convinced myself only/; you didn't prove it to me and I doubt you proved it to John. For example, I see from mercurial import changegroup if check_version(3, 0): cg = changegroup.getbundle(...) else: cg = repo.getbundle(...) and offhand it was unclear if the unconditional import was a mistake. Of course it wasn't a mistake. I doubt about the Of course part. The first reaction after seeing that the new changegroup is used only inside check_version(3,0) and nowhere else was to wonder if that import is necessary (or even safe) for the pre-v3.0 versions. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Really? Based on what reasoning? I have proven his reasoning to be basically wrong. Perhaps s/proven/convinced myself only/; you didn't prove it to me and I doubt you proved it to John. And you are still conveniently avoiding the question: Based on what reasoning? Of course it wasn't a mistake. I doubt about the Of course part. The first reaction after seeing that the new changegroup is used only inside check_version(3,0) and nowhere else was to wonder if that import is necessary (or even safe) for the pre-v3.0 versions. I don't care about your first reaction. If that was only present in newer versions, how do you think it would pass the testing on older versions? https://travis-ci.org/felipec/git Normally I would explain the details of why this is the case, and send the crash regresion fix for v2.0 with a clear explanation, but since you are adamant in threating git-remote-hg/bzr as just another crappy contrib script that doesn't even have tests like diff-highlight or hg-to-git. Why would I care? The fact that I'm the maintainer and I say it'ss good should be good enough, and if the current version in master renders unusable the existing Mercurial clones, hey, it's only in contrib, right? -- 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: [PATCH 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: And you are still conveniently avoiding the question: Based on what reasoning? Go re-read what was already said in the thread. I still think remote-hg and remote-bzr can and will flourish on their own merit, and unbundling will be better for the end users for the reasons stated there already. Having said that, I've been thinking (not because of this thread, but because I like imerge better and better these days) that there should be a much better way to have a list of recommended third-party plug-ins that enrich the Git ecosystem. We have https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools (Jakub cc'ed as he often nudges those who announce their tools to add an entry there) but honestly, git-scm.com is the first site the end users who do not hack on Git would visit, and we probably should have a catalog there (Scott and Peff cc'ed for that site). One way to help it may be to add a Documentation/gitthirdparty-tools.txt in my tree that would automatically be pulled into git-scm.com site as a part of the manual. A richer ecosystem with tools outside my tree would not materialize unless there is such a mechanism to advertise the existence of them, and having to include a copy of each and every third-party tools in my tree and keeping them relatively fresh is not going to scale in the long run (Michael and Matthieu Cc'ed as I saw exchanges on multimail in a near-by thread). Such a file would probably cluster plugins into different categories (post-receive hooks, remote-helpers, mergetools, etc.) and limit the entry descriptions to a single paragraph of several lines tops, with URL referring to the third-party maintainer's site (e.g. a repository at GitHub). Of course it wasn't a mistake. I doubt about the Of course part. The first reaction after seeing that the new changegroup is used only inside check_version(3,0) and nowhere else was to wonder if that import is necessary (or even safe) for the pre-v3.0 versions. I don't care about your first reaction. If that was only present in newer versions, how do you think it would pass the testing on older versions? https://travis-ci.org/felipec/git Normally I would explain the details of why this is the case, and send the crash regresion fix for v2.0 with a clear explanation,... Without such an explanation in the log message, how would you expect anybody to guess correctly? Seriously, if you do not care about my first reaction, why do you even want to live in my tree? The fact that I'm the maintainer and I say it'ss good should be good enough, and if the current version in master renders unusable the existing Mercurial clones, hey, it's only in contrib, right? One potential merit I would see for keeping them in my tree is that your change will see second opinions from others involved in the project (including me), without giving a total rein based on the sub-maintainership alone. All the changes from sub-area maintainers are vetted by at least two sets of eyeballs that way. But after having to deal with you and seeing that you do not take constructive criticism well, I doubt such a possibile merit will ever materialize in the area where you alone work on. Letting you do whatever you want in your own tree may benefit the users of remote-hg/remote-bzr better as the (bitter) second best option. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: Here's a bunch of tests more, and a fixes for Mercurial v3.0. I think the discussion with John Keeping hints that we shouldn't be rushing fc/remote-helpers-hg-bzr-graduation and this does not appear to assume the presense of that series, which is good in order to make these fixes jump over them. When merged to a place somewhere early between the next and the pu branches (aka the jch branch, which is the version I usually use myself), this seemed to break t5810, so I did today's integration cycle one more time by excluding this topic and then instead queuing it near the tip of the pu branch (read: today's 'pu' does not pass the test suite for me). There may be some other changes that this series depends on that I may have missed that caused this breakage. Can you take a look? Thanks. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: And you are still conveniently avoiding the question: Based on what reasoning? Go re-read what was already said in the thread. I already read it, and I already responded. I still think remote-hg and remote-bzr can and will flourish on their own merit, Oh, you *think*. Well, what if you are wrong? Or is that never a possibility? You are always right. Right? Having said that, I've been thinking (not because of this thread, but because I like imerge better and better these days) that there should be a much better way to have a list of recommended third-party plug-ins that enrich the Git ecosystem. If and when such a mechanism exists, sure, it makes sense to move functionality like git-p4 and git-remote-hg out of the core and contrib areas. But in the meantime what is ready for the core should be in the core. Normally I would explain the details of why this is the case, and send the crash regresion fix for v2.0 with a clear explanation,... Without such an explanation in the log message, how would you expect anybody to guess correctly? I don't. I told you it wasn't a mistake. If that's not enough for you, that's *your* problem. *If* git-remote-hg was to be part of the core, then sure, I would care that you didn't understand why the patch is correct, and I would resend immediately what a clear explanation. But since it's only part of the contrib area which has such abundant crap without documentation or tests. I do not care. Seriously, if you do not care about my first reaction, why do you even want to live in my tree? As I already explained; I don't care about your reaction *because* you don't want these tools to live in your tree. The fact that I'm the maintainer and I say it'ss good should be good enough, and if the current version in master renders unusable the existing Mercurial clones, hey, it's only in contrib, right? One potential merit I would see for keeping them in my tree is that your change will see second opinions from others involved in the project (including me), without giving a total rein based on the sub-maintainership alone. All the changes from sub-area maintainers are vetted by at least two sets of eyeballs that way. But after having to deal with you and seeing that you do not take constructive criticism well, Oh, please. Up to the point where you decided unilaterally to move them out of the core (they are alread in), all the constructive criticism to git-remote-hg has been addressed properly. I have spent an absurdely large amount of time working on git-remote-hg, and the transport-helper to make sure everything works right. I even started git-remote-bzr just to prove that the Python git_remote_helpers framework was not needed, and eventually I made it work better than any of the alternatives. I had to fight tooth-and-nail to prove that the msysgit guys were wrong and my patch to handle UNINTERESTING refs properly was right. Not to mention all the tests, the compatibility with hg-git, and with gittifyhg, just to prove that my approach was superior than the alternatives. I addressed every issue reported constructively, every bug report was fixed, every patch reviewed and usually improved by me. I made sure users of older versions wouldn't be affected negatively when the marks file was upgraded, and I even setup automatic tests for different versions Bazaar and Mercurial that run every time I push to my repository. It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Even you agreed it would be beneficial to move them out of contrib; it would benefit *everyone*. And there was no reason not to. And then some random guy comes with a few bad arguments, and you change your mind. That's f*cking double standards. Pure and simple. If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If git-remote-hg belongs in the contrib area, so does git-svn, and git-p4. After all this insane amout of work you are acting as if git-remote-hg wasn't ready to move to the core, because I didn't explain *one* commit properly to you (which happened after this bullshit). If these helpers are not going to move forward why would I care? Give me why one good reason why I should give a flying f*ck about the state of remote-helpers in *your* tree after this (and BTW as things stand now, it's not good). It was *your* users who urged me to send my patches upstream. I doubt such a possibile merit will ever materialize in the area where you alone work on. And there it is. Ad hominem rationale. Letting you do whatever you want in your own tree may benefit the users of remote-hg/remote-bzr better as the (bitter) second best option. If and when there is a mechanism promoting out-of-tree tools, that might be the case. In the meantime virtually every
Re: [PATCH 0/4] remote-hg: more improvements
Felipe, I would ask, suggest, beg, implore you to calm down. It's generally not a good plan to alienate the maintainer of a project, regardless of the correctness or incorrectness of one's arguments, but I fear that's only what you will achieve at the moment. -- Regards, James Denholm. -- 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: [PATCH 0/4] remote-hg: more improvements
Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: Here's a bunch of tests more, and a fixes for Mercurial v3.0. I think the discussion with John Keeping hints that we shouldn't be rushing fc/remote-helpers-hg-bzr-graduation and this does not appear to assume the presense of that series, which is good in order to make these fixes jump over them. When merged to a place somewhere early between the next and the pu branches (aka the jch branch, which is the version I usually use myself), this seemed to break t5810, so I did today's integration cycle one more time by excluding this topic and then instead queuing it near the tip of the pu branch (read: today's 'pu' does not pass the test suite for me). There may be some other changes that this series depends on that I may have missed that caused this breakage. Can you take a look? I'm such a bad maintainer and I don't take constructive criticism well why would you expect me to take a look? As usual, I did more than take a look and I went ahead to manually test with multiple versions of Mercurial. The problem appears with hg 2.6. Here's the fix: --- a/git-remote-hg.py +++ b/git-remote-hg.py @@ -905,7 +905,7 @@ def write_tag(repo, tag, node, msg, author): try: fctx = tip.filectx(f) data = fctx.data() -except error.ManifestLookupError: +except error.LookupError: data = content = data + %s %s\n % (node, tag) return context.memfilectx(f, content, False, False, None) -- 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
[PATCH 0/4] remote-hg: more improvements
Here's a bunch of tests more, and a fixes for Mercurial v3.0. Felipe Contreras (4): remote-hg: add more tests t: remote-hg: add file operation tests t: remote-hg: trivial cleanups and fixes remote-hg: add support for hg v3.0 contrib/remote-helpers/git-remote-hg | 6 +- contrib/remote-helpers/test-hg.sh| 240 ++- 2 files changed, 238 insertions(+), 8 deletions(-) -- 1.9.2+fc1.20.g204a630 -- 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
