William Giokas wrote:
> On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote:
> > 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.

Indeed, it *can* happen, nobody has argued otherwise. The thing is how
*likely* is it that it will happen again.

As I said, in my experience developing this there has never been a
single instance where such a change was required for *newer* versions of

>From what I can tell this is an exceptional situation.

And it makes sense that when it happened, it happened exactly in the
part where I wrote custom push() method. Mercurial has unstable API, but
in unstable API's are part that are more stable than others. Generally
the higher level the API is, the more stable it tends to be.

The Linux kernels makes an even weaker promise of API stability than
Mercurial does, but even then, the higher the API you use, the less
likelihood you have of breakage. I've seen this in practice many times.

And it does makes sense that for practical purses Mercurial would try to
avoid changes in the higher level API, which require changes in many
places, and not so much in lower level APIs, which might require a few
changes here and there.

The problem is that in order to replace the higher level API push(), I
had to use the lower level API, and that's where the breakage happened,
it was not unlikely. It is unlikely that another change in this
particular API will happen soon, but not extremely so.

As I already explained, this can be mitigated by contacting the
Mercurial developers and figure out if their high-level API can
accommodate the kind of functionality git-remote-hg needs. Maybe by
adding a new option, or maybe by adding another high-level helper

Either way, I doubt Junio is qualified at all to discern between the
likelihood of future Mercurial API changes that would break
git-remote-hg. He has seen one, and he is wrongly assuming there are
more to come.

> 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.

How exactly would it be better?

If you concede that the Git release wouldn't be affected, then assuming
a hypothetical future where git-remote-hg is bundled, and we have a
Mercurial API breakage, we would have:

 Git < v2.5 fail, Git >= 2.5 get the fix

If we unbundle, we have:

 git-remote-hg < v0.5 fail, git-remote-hg >= v0.5 get the fix

What is the big difference?

I presume you would say that git-remote-hg v0.5 could be released
earlier than Git v2.5, so the users would get the fix faster. However,
that is not the case if the breakage is detected *before* the Mercurial
release happened, in which case both Git v2.4 and git-remote-hg v0.4
would already contain the fix, and it doesn't matter much which was
released first.

The problem is that I wasn't doing the continuous integration with the
development version of Mercurial, which I am now, so these kind of
exceptional issues would be detected earlier.

Moreover, it is likely that the distribution package for git-remote-hg
would not be maintained as rigorously as the Git package. It might not
even be part of the official packages (e.g. ppa or AUR). Therefore, even
if the git-remote-hg v0.4 happens earlier, it might reach the users

Furthermore, we are talking about a single script that can be installed
by hand easily. The users can simply override their distribution's
script and install by hand the latest version, as many have been doing
already when they report errors and want the latest fix.

Even more. git-remote-hg will not have maintenance releases, if an
exceptional issue like this happens, it can be back-ported to Git v2.3.x,
Git v2.2.x, and so on.

It seems like a very feeble argument in favor of unbundling *at best*.

> 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.

That is not true. In this particular case, because I didn't build
against the development version of Mercurial, yes, but not for the

If I had the tests I have in place now, we would have detected the
change earlier, and Git v1.9.2 would *already* contain the fix, and when
Mercurial v3.0 got released we wouldn't need to make a Git release in
response (same goes for unbundled git-remote-hg).

> 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.

As I said; that won't happen. This was an exceptional situation for
different reasons.

If git-remote-hg was unbundled, and the correct tests in place, I would
have v0.2 already with the fix for hg 3.0, and when hg 3.0 got released
I wouldn't be forced to make another v0.2 release. Additionally, I would
not need to make the v0.2 release because of a fix for hg 3.0-dev as

In other words; the releases wouldn't be as tightly coupled as you make
them seem.

> This goes for bzr, too, but it looks to be changing less quickly.

More like not at all.

> tl;dr: This may not block a release, but it will make releases a lot
> more dependent on outside forces.

tl;dr: That won't happen. Even if it did, it would happen in the
unbundled release a well.

Also note that Junio never brought these points, and they were never

I think if I had the tests for the Mercurial development version, the
fix for hg 3.0 would be already released in Git 1.9.2, and I find it
very likely that the graduation to the core would not have been tainted
by this extremely exceptional situation, and the graduation would
continue just fine for Git v2.1.

Sadly we would never know, because people are not good with thought
experiments, and they can't see what such a situation would look like,
and how a similar exceptional situation would look just like that. Not
to mention the fact that suck situation wouldn't happen at all.


Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to