Junio C Hamano wrote: > Philippe Vaucher <philippe.vaucher@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html