Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

[Junio C Hamano <gitster@pobox.com>]

Chris Packham <judge.packham@gmail.com> writes:

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

While I agree that submodules may be useful for git-gui and gitk
(which already have their own repository and history), I do not
think that affects the issue of release cycles for third-party tools,
especially the ones with heavier foreign system dependencies like
vcs interfaces.

The release schedule of Git itself places a lot of stress not to
regress anything for existing users of Git, and the gitlink that
points at the specific commit in a submodule will stop advancing in
the top-level superproject (i.e. my tree) during the feature-freeze
period before releases, just like any other paths (i.e. regular file
blobs).

A third-party product maintainer may have other ideas about
stability of their product.  They may want to issue an unproven new
release to adjust to a recent update made to their external
dependencies as soon as code is written, relying on their ability to
issue follow-up maintenance updates on their product in quick
succession.  If many of them are bundled with Git, then we would
have to keep following these "oops, that was wrong" updates from all
of these, which would add unscalable burden to a single choking
point.

Not bundling gives third-party tools the freedom to evolve and worry
about compatibility with their dependencies on their own, and allows
them to treat Git as just one of the dependencies at the same level
as their other dependencies.