On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote: > Junio C Hamano wrote: > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > > == contrib vs. core == > > > > > > This is the only point relevant to contrib vs. core: > > > > > > > - We may be painted in a hard place if remote-hg or remote-bzr take > > > > us to a position where the Git as a whole is blocked while it is > > > > incompatible with the other side. > > > > > > It will never happen. I already argued against it[1], multiple times. > > > Essentially making the tests optional removes any possibility of > > > blockage (pluse many more arguments). > > > > I already said that your "It will never happen" is a handwaving, and > > I already saw you "argued against it". > > This is a red herring. Ignore the fact that it will never happen (which > it won't), the next point remains a FACT, and you conveniently ignore > it. It may not block git being released, but as we can see from the recent patches that were needed to enable hg 3.0 support it can break and would have to follow *both* mercurial and git upstreams, not just git's. After thinking about this for a while, I would have to agree with Junio That it's better if a bridge between to actively developed applications not be coupled to one. This does not mean that I think git-remote-hg is not of a quality to be in the git.git tree, but it is simply a fact of development and stability. If git's remote-helper stuff changes but mercurial doesn't, we're fine because, having seen the speed of your fixes, we would have a fix before the next release without a doubt. However, if mercurial changes, like it just did, then git itself would need to make a release to have it actually work with the newest release. Having the tool out of tree allows the maintainer to fix things on both ends and release independently so that both situations above can be solved without any real hassle on git or mercurial's side. This goes for bzr, too, but it looks to be changing less quickly. tl;dr: This may not block a release, but it will make releases a lot more dependent on outside forces. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Attachment:
pgpkoOG5HpG7H.pgp
Description: PGP signature