Re: [PATCH v2 01/17] contrib: remove outdated README

[William Giokas <1007380@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote:
> Junio C Hamano wrote:
> > Felipe Contreras <felipe.contreras@gmail.com> 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 #2: Type: application/pgp-signature, Size: 836 bytes --]