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

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

On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
> 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.