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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 6, 2014, 00:20 UTC
Message-ID: <53682ae027b7d_24f8d2930881@nysa.notmuch>
In-Reply-To: <xmqqoazb944d.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

> John Keeping <john@keeping.me.uk> writes:

Show 15 quoted lines

> > In the case of git-remote-hg specifically, the remote helper has to use
> > an interface that the Mercurial developers consider unstable [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].
> 
> The same argument would apply to git-svn, git-p4, and git-cvsimport,
> I would think.
> 
> Among these, I am not sure if we can find willing maintainers who
> can give enough love to them.  But unlike these other importers,
> remote-hg and remote-bzr do have an active maintainer (and IIRC I
> think I heard that Hg one even has an active competitor or two?)

Unfortunately there are no more real competitors to remote-hg. A far as I can tell msysgit has dropped their remote helper, and gitifyhg is not being actively maintatined and it's even pointing to our git-remote-hg as probably the best alternative to use at the moment.

> so I am reasonably confident that these can live on their own merit
> outside of my tree.  In the ideal world, I would think it may be even
> beneficial to the end users of these helpers to unbundle them.

It might be benefitial in the future, but right now I'm willing to bet there's many people that don't know git-remote-hg/bzr even exist. If Git v2.0 distributes them by default, and they are mentioned in the release notes:

 * Transparent support to pull and push to and from Mercurial and Bazaar
   repositories is now enabled by default.

Many more people will know about that, and in the future when we try to unbundle them they can shout if for some reason it would be inconvenient for them. At the moment I don't think we can say for sure.

Even if people don't use these bridges, I think just mentioning that feature helps the project in general.

> You raised a good point on the issue of external dependencies may
> impact Git as a whole, even for those who are not interested in the
> particular remote helpers at all.  I'll have to think about it.

Yes, it's worth thinking about it because it's a real possibility. However, real possibilities are many times not likely to happen, and I think this is one of those cases.

As I've said, if history is any indication these issues won't happen. As far as I can remember the only issues that have happened are backwards compatibility issues, not present or future. And as I said I've setup TravisCI builds to detect those, which is why we haven't had those issues since then.

> So it boils down to "how much resource are there to make sure a helper
> will stay compatible with wider versions of both sides?" and "how far
> backwards are helper maintainers willing to bend to support users
> better?".

This is not that big of an issue. For example, notice how the changes in the transport-helper to enable say --force and --dry-run did not require to align changes in remote-hg/bzr. That's because remote-hg/bzr had already the code for these features, it was just not exercised until the transport-helper was modified.

I think the current transport-helper infraestructure is already good enough to detect the features and options of the remote helpers so unbundling wouldn't be a major problem.

Having said that alignment issues do happen, and we have one of those in Git v2.0, but I don't think they are a major concern (at least for remote-hg/bzr).

-- 
Felipe Contreras