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

Event #2:
I give up improving remote helpers in git.git

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

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

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

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

Reply via email to