Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@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 tool that is worth using lives in
git.git and is distributed by default. Everything else is sub-par in the
minds of Git users.

One tool being dropped from the tree while other tools remain there is
not going to send a positive message to its users.

If you are so confident git-remote-hg would "flourish" out-of-tree, drop
git-p4 and git-svn, see what is the reaction.

-- 
Felipe Contreras