Hi,
On 06/05/14 11:50, Junio C Hamano wrote:
> 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.
A bit of a crazy suggestion and a little off-topic. Assuming maintainers
can be found what about having these foreign vcs interfaces as
submodules. That way they can be in Junio's tree as well as having their
own release cycles. The same could apply to git-gui, gitk and gitweb. It
would also be a chance to eat-our-own-dogfood with submodules.
> 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
>
--
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