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

From: John Keeping <john@keeping.me.uk>
Date: May 6, 2014, 08:07 UTC
Message-ID: <20140506080749.GD23935@serenity.lan>
In-Reply-To: <xmqqoazb944d.fsf@gitster.dls.corp.google.com>

On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> John Keeping <john@keeping.me.uk> writes:
> 
> Having said all that, there is one caveat.
> 
> > 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.
> 
> You are correct to say that a remote helper has to talk with a
> foreign system and it would not help to dictate the update schedule
> of helpers to match the release cycle of Git itself.  At the same
> time, however, the interface the remote helpers use to talk to Git
> has not been as stable as you seem to think, I am afraid.  For
> example, a recent remote-hg/bzr series needed some enhancements to
> fast-import to achieve the feature parity with native transports by
> adding a missing feature or two on the Git side.

This doesn't qualify as an unstable interface for me. In this case, the remote helpers could not support a feature without Git supporting it first, which is quite natural and the remote helper can then guard that feature with a capability check. I do not think it likely that the remote helper interface will ever change in such a way that all remote helpers must be updated, at least not without a long deprecation period.

The Mercurial API makes no such guarantee; it is considered a private implementation detail and most releases seem to contain some changes that require all consumers to be updated.

There is a different level of urgency between "you cannot use this new feature until you update Git" and "if you update Mercurial then the remote helper will stop working", and that's why I think the remote helpers may benefit from a separate release schedule.