Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

[John Keeping <john@keeping.me.uk>]

On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>  - remote-hg: trivial cleanups
>  - remote-hg: make sure we omit multiple heads
>  - git-remote-hg: use internal clone's hgrc
>  - t: remote-hg: split into setup test
>  - remote-hg: properly detect missing contexts
>  - remote-{hg,bzr}: store marks only on success
>  - remote-hg: update to 'public' phase when pushing
>  - remote-hg: fix parsing of custom committer
>   (merged to 'next' on 2014-04-22 at fed170a)
>  + remote-helpers: move tests out of contrib
>  + remote-helpers: move out of contrib
>  + remote-helpers: squelch python import exceptions
> 
>  Move remote-hg and remote-bzr out of contrib/.  There were some
>  suggestions on the follow-up fix patches still not in 'next', which
>  may result in a reroll.
> 
>  Will merge to 'next' and keep it there for the remainder of the
>  cycle.

I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.

I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting associated tools when Git was young and had
not established mindshare, Git is now by far the most popular DVCS and
is rapidly catching up with centralized systems.  Associated tools can
therefore live on their own and do not need to be promoted as part of
Git itself (as git-imerge is doing successfully).

In the case of git-remote-hg specifically, the remote helper has to use
an interface that the Mercurial developers consider unstable [1]; the
version currently on 'pu' fails the test suite for me because I have
Mercurial 3.0:

	AttributeError: 'mqrepo' object has no attribute 'getbundle'

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 [2].

Since the remote helper interface is stable and the remote helpers do
not use any of the Git internals, I consider the risks of including them
in core Git to outweigh the benefits of wider distribution.  In fact,
the remote helpers may benefit from having their own release cadences
so that they can respond to changes in related projects more quickly
than the normal Git release cycle.


[1] http://mercurial.selenic.com/wiki/MercurialApi#Why_you_shouldn.27t_use_Mercurial.27s_internal_API
[2] https://bugs.gentoo.org/show_bug.cgi?id=418431