Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > So you grant that there is no reason anybody can think of why we would ever > > want a post-update-branch? > > No, it only shows that you (and I) are not imaginative enough > (and/or we didn't bother spending enough brain cycles) to come up > with an example. That is the same thing; nobody can think of a reason. > Your lack of imagination and foresight does not give you any right to close > the door to those who come after you who have real needs, or make it awkward > to add it later for them. No, but rationality and evidence are the only things we can use to make decisions, and there is no reason to think something is going to happen, I don't see why any rational person would think that it would. > > Let's make a bet, we go for 'pre-update-branch' and five years from now, if > > there's no 'post-update-branch', you will publicly accept thta I was right. > > > > Deal? > > Let me get this straight. You spent a lot of effort to argue that > naming it update-branch is the right thing, but now you want me to > name it pre-update-branch, only so that you can prove you are right? That is right. It's impossible to convince you with logic and evidence, and even when you are shown to be wrong, you don't accept it. There is literally nothing anybody can do to convince you that imaginary fears are just imaginary. At the end of the day your conclusion will be that the improbable is still possible, well anything is possible, so saying "I don't see how A could happen, but it's possible" is really not saying anything at all. So yes, the only thing I can do is give up, however if you have any stakes in progress of Git you would put your money where your mouth is. If you had already done your job you should have some certainty on whether a 'post-update-branch' is going to happen or not. If you don't have such certainty enough to make a bet, then why should anybody trust your conclusion? > For the rest of us, making Git better is the primary reason why we are here. > You seem to be saying that it is more important to you, however, to "win" > your little argument, and you are willing to even sacrifice a better Git (in > your mind, with the hook named as update-branch) in order to "win". I can't make Git better if you don't humble yourself. You need to accept when you are wrong. If I say "A is not going to happen" and I provide evidence, but you say it would, and indeed it doesn't happen, maybe when I say "B is not going to happen", maybe you would actually listen, and if not, maybe when I say "C is not going to happen" you would. But if you are only willing to accept you were wrong when it's safe, then how is anything going to change for the future. > With a person with such screwed-up priorities, nobody whose first > objective is to make Git better can have a sane conversation. You are the one with the screwed priorities. Time and time again the #1 issue people have raised about Git is the user-interface. We even had Git user surveys to try to find out what people wanted. In these surveys the last thing people wanted was better performance, yet most Git developers are still focusing on performance. What people said needed improvement was the user-interface and documentation, yet *nothing* has changed in these two areas. It's not a wonder no more surveys are launched; because the results of such surveys are ignored anyway. If a project has screwed-up priorities, it's when the areas of improvements users say are needed get ignored. > if you want another example, where you try to twist words by Peff and others > and caught in doing so. This is plainly intellectually dishonest. One year ago I made a summary of what others said[1], I tried to keep it verbatim, CC'ed them, and invited them to clarify if their position was misrepresented. Nobody, not even Jeff complained about that. Now, my mistake was thinking that "A is better" meant "we should go for A", however, that wasn't the case for Jeff. I didn't twist any words, I made a wrong assumption. However, I bet most people in that list agree that "we should go for A", and if you want, I can ask them all again (except Jeff, because we know his answer). But I bet you are not interested in what they (or for that matter anyone) think on the matter. And you know it was an easy mistake to make, to accuse me of twisting words is just dishonest. > It could be that your "bet" is a way for you to finally admitting > that naming the hook with "pre-" prefix will result in a better Git > than without, without you having to say "Yes, you are right, let's > change it" (which I rarely if ever saw you doing). But still that > shows the same screwed-up priorities---winning your little argument > (or not losing it) matters more to you than working well with > others. I do not think I want to work with such a person. That is not it at all. How am I going to convince you of anything controversial in the future, if you are never willing to admit that you were wrong, and pay a small public face price? The fact of the matter is that you don't want to be wrong, you don't want to be shown to be wrong, and you don't want to accept you were wrong. Therefore you reject any experiment in tha direction, and you ignore things like the user survey that shows your priorities are wrong. *This* is what hurts the project, not my "bet". Now, if you had any certainty on what you are saying, you would say "Sure", win the bet, and nothing bad would happen, users would have "pre-update-branch" and "post-update-branch", and everybody would be happy (except me a little bit because I was wrong). But the fact of the matter is that at some level you already know there won't be any "post-update-branch", I guess that's why you decided to attack me personally instead of dealing with your cognitive dissonance and accept that fact. [1] http://article.gmane.org/gmane.comp.version-control.git/233469 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html