Re: Should git-remote-hg/bzr be part of the core?

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

Michael Haggerty wrote:
> On 05/12/2014 12:37 PM, Felipe Contreras wrote:
> > Michael Haggerty wrote:
> >> On 05/12/2014 01:34 AM, Felipe Contreras wrote:
> >>> Recently Junio said he was willing to hear the opinion of other people
> >>> regarding the move from contrib to the core[1]. This move is already
> >>> under way, but suddenly Junio changed his mind.
> >>
> >> I agree with Junio.  There are good technical arguments for and against
> >> moving git-remote-hg out of contrib.
> > 
> > Saying you agree with Junio is content-free. You have to say *why* you
> > agree.
> 
> Actually, I don't have to,

Then there's no point in reading what else you have to say. Whatever
reasons you might have to agree with Junio are known only to you, thus
your "agreement" is opaque and meaningless.

> > The quality of the subjproject has not been called into question, stop
> > taiting the discussion with red herrings.
> 
> On the contrary.  I just called the quality of the subproject into
> question, and I stated exactly which aspects of its quality I find to be
> inadequate in the text that you omitted from your response:

I'll wait until somebody else calls into question the quality.
Preferably somebody who backs up his claims with evidence.

> OK, maybe you are technically correct there.  There is indeed a
> difference between > and >=.  Let me amend my claim:
> 
> 2. Moving git-remote-hg into the core would require you to continue your
>    presence on the Git mailing list.

That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would also require my presence on the list. Is
that what you want?

And there's the transport helper, and bash completion, and the zsh
completion.

> >>> [...] Does it make sense to you that
> >>> you get thrown in jail for a crime you haven't committed merely because
> >>> someone thinks it's likely you will?
> >>
> >> Being the leader of your own valuable open-source project is nothing
> >> like jail.  It is an opportunity for you to shine in an environment that
> >> is more suited to your personality.
> > 
> > Don't be ridiculous. There is no out-of-tree tool that could possibly
> > compete in popularity against core tools.
> 
> I never made that claim.  I claimed that it was "nothing like jail", and
> I stand by that claim.

In the context of the Git project what is the *worst* thing the
maintainer can do to a piece of code but delete it? So I think you are
right, the jail analogy is not correct; it's *execution*.

> > You know that those tools do better in the core, and you know
> > git-remote-hg/bzr would do better in the core. Don't act as if you
> > didn't.

> People who need to do a conversion from A to B only have to Google for
> "A B" and they will find the best conversion tools pretty easily.

Let's test that hypothesis:

Google: how to conver mercurial to git

 * Convert Mercurial project to Git - Stack Overflow (NOPE)
 * Converting a Mercurial repository to Git (YEAP: one among many)

Oh, but would you look at that:

  This script will actually be shipping with git at some point, which
  gives it some credibility in my book.

 * frej/fast-export · GitHub (NOPE)
 * Hg-Git Mercurial Plugin (NOPE)
 * Converting Hg repositories to Git (NOPE)
 * Converting from Mercurial to Git - Hivelogic (NOPE)
 * Converting Repositories From Git to Mercurial (NOPE)
 * hg-fast-export: convert Mercurial repositories (NOPE)
 * Converting Mercurial (Hg) to Git Repository on Mac (NOPE)
 * Bitbucket: Converting Hg repositories to Git (NOPE)

So pretty much hypoethesis failed. That fact that you would even think
people would quickly find about git-remote-hg shows exactly how detached
you are from the problem.

> If the tools are packaged for their OS then they are just an "apt-get
> install" away from happiness.

Oh, they are packaged already (as part of Git). Moving them out-of-tree
will make it much more difficult for users to find them, and install
them. It will take time for them to be packaged, if it happens at all.

> > Let's see how sincere you are in your sentiment. I'll reply to you
> > personally about the points that I consider to be red herrings and ad
> > hominem attacks so we don't taint the dicussion. If you don't reply I'll
> > know you were not being sincere.
> 
> Jumping at your every demand is not a prerequisite for being sincere.

I spent a lot of time writing that mail. Not sincere it is then.

-- 
Felipe Contreras