On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote: > John Keeping <john@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html