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

From: John Keeping <john@keeping.me.uk>
Date: May 5, 2014, 18:45 UTC
Message-ID: <20140505184546.GB23935@serenity.lan>
In-Reply-To: <xmqq7g67iwxc.fsf@gitster.dls.corp.google.com>

On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> * 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