Thread (8 messages) 8 messages, 3 authors, 2016-06-15

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

From: Felipe Contreras <hidden>
Date: 2016-06-15 23:01:06

Michael Haggerty wrote:
On 05/12/2014 12:37 PM, Felipe Contreras wrote:
quoted
Michael Haggerty wrote:
quoted
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
quoted
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.
quoted
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.
quoted
quoted
quoted
[...] 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*.
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help