On Thu, Aug 22, 2019 at 01:23:59PM -0700, Junio C Hamano wrote:
> 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.
I like the general line of thinking here, but let me Devil's Advocate
your Devil's Advocate:
- having separate repos and release schedules means that the
dependency changes need to be coordinated. E.g., if a feature in
git-filter-repo needs a new feature in git-core, then the feature
needs to land in git-core first, then filter-repo needs to decide
how to handle older versions. Whereas in the same repo, they can
generally assume to move forward atomically.
- some of the non-core stuff helps test coverage for the core parts of
the system. E.g., what bugs might we find in fast-import that are
only triggered by the filter-repo test suite? Similarly, the
scripted tools in git.git often serve as canaries for
backwards-incompatible changes to the plumbing.
Something like the meta-git.git that Stolee proposed would help with
that. But then we may end up dealing with other people's messes,
which is one of the things we'd try to avoid with such a split.
-Peff
