Elijah Newren <newren@xxxxxxxxx> writes: > Questions, comments, or concerns with this proposal? Alternative > proposals? If inclusion is acceptable, are there any other tasks that > need to be completed first? I do not want a discussion to begin with a Devil's Advocate response, but anyway... Are we planning to go to all batteries included approach? I have a feeling that there are other tools (hello, "git imerge") that equally deserve attention by Git users; are we in the business of absorbing them all? How big a project will our tree become, and how much more activity would have to be haneld by the readership of the Git mailing list? I'd rather see us shed non-core tools we already have (e.g. git-svn, cvs import/export) out of git.git and have them as independent projects. But that may be just me. The benefits I see in the "leave as much as possible out" approach are (not in particular order): - Distributed development and integration. The release schedule of Git-core does not have to be constrained by the readiness of non-core part. - Choice of development tools, language, etc. The core part will stay in C, but peripheral tools do not have to be constrained by our choice. Those who run their own project can choose what they want to use and how they want to structure their development process. The primary downside I would want to avoid from absorbing non-core stuff is that such peripheral tools (git-cvsimport, I am looking at you) can go stale when their development stalls, and nobody would be bold enough to suggest removing them.
