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

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

John Keeping wrote:
> 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).

Then let's remove git-p4.

> In the case of git-remote-hg specifically, the remote helper has to use
> an interface that the Mercurial developers consider unstable [1];

There is no other sensible way of doing them.

> the version currently on 'pu' fails the test suite for me because I
> have Mercurial 3.0:
> 
> 	AttributeError: 'mqrepo' object has no attribute 'getbundle'

And because this patch has not been picked up[1].

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

Travis-CI ensures that won't happen[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.

Maybe, but git-remote-hg has already benefitted a lot from the wider
exposure of being in 'contrib/', I'm sure it would benefit even more if
it's distributed by default.

Moreover, there's a ton of subpar tools out there[3], and I believe
giving the burden of choosing one to the user is detrimental to the Git
project. If we as a project say: this is the one we recommend, and has
the Git stamp, that helps the users tremendously.

Your point is valid though, but it's valid not just for
git-remote-hg/bzr.

So I think these are the two options:

  1) Include git-remote-hg/bzr to the core and distribute them by
     default (as is the current intention)

  2) Remove git-remote-hg/bzr entirely from the Git tree. And do the
     same for other tools: git-p4, git-svn, git-cvs*. Given the huge
     amount of people using Subversion, we might want to defer that one
     for later, but eventually do it.

I'd say for v2.0 we should go for 1), and 2) should be considered for
v3.0, perhaps.

[1] http://article.gmane.org/gmane.comp.version-control.git/248065
[2] https://travis-ci.org/felipec/git
[3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives

-- 
Felipe Contreras