From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:00
John Keeping [off-list ref] writes:
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
quoted
* 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?".
From: John Keeping <hidden> Date: 2016-06-15 23:01:01
On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
Having said all that, there is one caveat.
quoted
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.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:01
Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
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?)
Unfortunately there are no more real competitors to remote-hg. A far as
I can tell msysgit has dropped their remote helper, and gitifyhg is not
being actively maintatined and it's even pointing to our git-remote-hg
as probably the best alternative to use at the moment.
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.
It might be benefitial in the future, but right now I'm willing to bet
there's many people that don't know git-remote-hg/bzr even exist. If Git
v2.0 distributes them by default, and they are mentioned in the release
notes:
* Transparent support to pull and push to and from Mercurial and Bazaar
repositories is now enabled by default.
Many more people will know about that, and in the future when we try to
unbundle them they can shout if for some reason it would be inconvenient
for them. At the moment I don't think we can say for sure.
Even if people don't use these bridges, I think just mentioning that
feature helps the project in general.
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.
Yes, it's worth thinking about it because it's a real possibility.
However, real possibilities are many times not likely to happen, and I
think this is one of those cases.
As I've said, if history is any indication these issues won't happen. As
far as I can remember the only issues that have happened are backwards
compatibility issues, not present or future. And as I said I've setup
TravisCI builds to detect those, which is why we haven't had those
issues since then.
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?".
This is not that big of an issue. For example, notice how the changes in
the transport-helper to enable say --force and --dry-run did not
require to align changes in remote-hg/bzr. That's because remote-hg/bzr
had already the code for these features, it was just not exercised until
the transport-helper was modified.
I think the current transport-helper infraestructure is already good
enough to detect the features and options of the remote helpers so
unbundling wouldn't be a major problem.
Having said that alignment issues do happen, and we have one of those in
Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:01
Felipe Contreras wrote:
Having said that alignment issues do happen, and we have one of those
in Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
Actually I just noticed that the remote-helpers side is not in the
"master" branch.
I don't know what is your plan with fc/remote-helpers-hg-bzr-graduation,
but for v2.0 we really want the patch 'remote-{hg,bzr}: store marks only
on success'. Explaining precisely why would take a lot of effort, but
basically it's related to 3994e64 (transport-helper: fix sync issue on
crashes).
If you are worried about merging the whole branch, I could pick only the
important patches and reroll.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:01
John Keeping wrote:
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",
s/the remote helper will stop working/certain features of the remote
helper *might* stop working, but we are trying hard to make sure that
doesn't happen/
--
Felipe Contreras
From: Chris Packham <hidden> Date: 2016-06-15 23:01:03
Hi,
On 06/05/14 11:50, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
quoted
* 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.
quoted
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Felipe Contreras <hidden> Date: 2016-06-15 23:01:03
Chris Packham wrote:
On 06/05/14 11:50, Junio C Hamano wrote:
quoted
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.
If submodules were an integral part of Git that would be a possibility,
but they are more like a hack.
--
Felipe Contreras
From: David Lang <hidden> Date: 2016-06-15 23:01:04
On Thu, 8 May 2014, Felipe Contreras wrote:
Chris Packham wrote:
quoted
On 06/05/14 11:50, Junio C Hamano wrote:
quoted
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.
If submodules were an integral part of Git that would be a possibility,
but they are more like a hack.
Well, if git.git can't use them, then how can anyone else be expected to.
I haven't been paying close attention for a while, what would have to be done to
make submodules "an integral part of Git"?
David Lang