git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: git@vger.kernel.org, git-fc@googlegroups.com
Cc: "Richard Hansen" <rhansen@bbn.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	"Antoine Pelisse" <apelisse@gmail.com>,
	"Christophe Simonis" <christophe@kn.gl>,
	"Dusty Phillips" <dusty@linux.ca>, "Jeff King" <peff@peff.net>,
	"John Keeping" <john@keeping.me.uk>
Subject: Should git-remote-hg/bzr be part of the core?
Date: Sun, 11 May 2014 18:34:08 -0500	[thread overview]
Message-ID: <537008f06ceb8_8e47492f89f@nysa.notmuch> (raw)

Hi,

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 have repeatedly asked him to clarify what argument changed his mind,
but he hasn't done so. Hopefully he will do that in this thread, but
I'll jump ahead and assume it's this one by John Keeping[2]:

  I do not want to end up in a situation where an update to Git is
  blocked by a distribution because git-remote-hg is not updated to
  support newer versions of Mercurial sufficiently quickly; this
  previously happened in Gentoo due to git-svn and meant that was stuck
  on 1.7.8 until 1.7.13 was released [X].

Now, I feel I addressed this argument at length, specially in this
thread [3], but I'll try to provide a summary of the strongest arguments
against:

 1) We can make the tests optional, say 't/optional'. So if they don't
    pass, the build of Git is not broken. Additionally, distributions
    might prefer to run test-essential if they don't want to run these
    optional tests.
 
 2) There's already continuous integration builds[4] to make sure all
    the possible incoming changes in Mercurial are detected early on.

 3) There has been a *single* case where a new Mercurial (3.0) broke
    things. This is due to the fact of how I implemented certain
    functionality due to limitations in Mercurial's API. Mercurial
    authors can be contacted to improve the API and minimize the
    possibility of it happening again.

Given these arguments, I don't see how moving git-remote-hg to the core
could possibly cause any problems, and I don't understand why Junio
would think otherwise. Even if such a breakage causes a problem to the
whole Git, it would make sense to demote these tools *when* such a
problem comes (which I argue it won't). 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?

Given the huge amount of work I've put in these remote helpers, and the
fact that Junio said since day 1 he wanted these in the core[5] (and I
was operating under that assumption), I think the demotion back to the
contrib area (and therefore out-of-tree) should be made carefully, and
not from one day to he next as it happened.

Thoughts?

[1] http://article.gmane.org/gmane.comp.version-control.git/248676
[2] http://article.gmane.org/gmane.comp.version-control.git/248167
[3] http://article.gmane.org/gmane.comp.version-control.git/248683
[4] https://travis-ci.org/felipec/git
[5] http://article.gmane.org/gmane.comp.version-control.git/220277

-- 
Felipe Contreras

             reply	other threads:[~2014-05-11 23:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-11 23:34 Felipe Contreras [this message]
     [not found] ` <CA+55aFwf9iAKxbvdPV9Up_T709KwBXJWW4g-F829CRQP4YkivQ@mail.gmail.com>
2014-05-12  7:42   ` Should git-remote-hg/bzr be part of the core? Felipe Contreras
2014-05-12  8:12     ` Felipe Contreras
2014-05-12 10:28       ` Stefan Beller
2014-05-12 12:05         ` Felipe Contreras
2014-05-12  9:42 ` Michael Haggerty
2014-05-12 10:35   ` Dennis Kaarsemaker
2014-05-12 10:37   ` Felipe Contreras
2014-05-12 12:05     ` Michael Haggerty
2014-05-12 12:29       ` Felipe Contreras
2014-05-12 13:12         ` David Kastrup
2014-05-12 17:12           ` Felipe Contreras
2014-05-12 13:43         ` Michael Haggerty
2014-05-12 17:13           ` Felipe Contreras
2014-05-12 11:00   ` David Kastrup
     [not found]   ` <CAHVLzcmqdkf4fMTok+HsXcDOQ5Oz2QdZti3FuzgBUa2T6AWnfA@mail.gmail.com>
2014-05-12 12:48     ` Felipe Contreras
2014-05-12 13:45       ` Paolo Ciarrocchi
2014-05-12 16:13         ` Stefan Beller
2014-05-12 16:40         ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537008f06ceb8_8e47492f89f@nysa.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=apelisse@gmail.com \
    --cc=christophe@kn.gl \
    --cc=dusty@linux.ca \
    --cc=git-fc@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    --cc=peff@peff.net \
    --cc=rhansen@bbn.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).