John Keeping <john@xxxxxxxxxxxxx> writes:
> On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>> ...
>> Move remote-hg and remote-bzr out of contrib/. There were some
>> suggestions on the follow-up fix patches still not in 'next', which
>> may result in a reroll.
>>
>> Will merge to 'next' and keep it there for the remainder of the
>> cycle.
>
> I'd like to register my opposition to moving git-remote-{bzr,hg} out of
> contrib/.
> ...
> 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?) 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.
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.
The silly thing is that I totally forgot that we almost got
ourselves into a very similar situation on cvsimport when a series
wanted to make it cvsps3-only. It is very possible nobody would
have picked up the entire new release, if we merged that change.
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.
So in reality, a helper has to talk with two sides, needs to adjust
to changes in the both sides, and both sides are changing.
Unbundling a helper from Git would place more burden on the helper's
maintainer, because the helper has to know enough about versions and
features of both sides (the foreign system and Git) to adjust its
behaviour, to stay compatible with wider versions of both foreign
systems and Git. Unbundling, when done properly, may give more
ideal user experience to the end users, because such a helper would
allow them to pick up the latest (or stay on an older but known to
be stable) version of the helper and expect it to work with the
foreign system and Git they happen to have.
It however would be easier to maintain if the helper maintainer
knows a change to Git itself will be released at the same time as
the new version of the helper that takes advantage of the modified
Git. The helper maintainer only has to worry about compatibility
with the foreign side if it is bundled with Git.
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?".
--
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