Understanding the relationship of mercurial and it's extensions

[Marcin Kasperski]

> the presence of that extension (experimental and not deprecated) seems
> to indicate that it is intended to be made better eventually. One way
> to do that, if that third-party extension is really so much better,
> would be to capitalize on it and, if possible, bring it inside.

Disagree.

(hg-git specific)

1. hg-git has non-trivial dependencies (dulwich) so „bringing it inside”
   would also mean managing such external dependency (from resolving
   problems with having it installed on all supported platforms to
   making new Mercurial releases in case some incompatible change
   is brought into such dep).

(general remarks about core/non-core extensions)

2. Plenty of people use „older” Mercurials (which they find packaged on
   various distributions/systems). Author of externally managed
   extension can opt to support such older mercurial versions, giving
   users chance to install extension updates without the need to install
   mercurial.

3. Combining releases always introduce additional effort. If extension
   is developed and maintained by separate author or team, it is easier
   for them to develop it and publish releases whenever some functionality
   is ready than to offer patches and wait for mercurial release. The
   bigger and more complicated the extension, the more it matters.


PS IMHO word „experimental” is overused by Mercurial, also some error
handling routines tend to blame extensions far too easily.