Chris Packham <judge.packham@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html