On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
> John Keeping <j...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html