Re: RFC: Proposing git-filter-repo for inclusion in git.git

From: Jeff King <peff@peff.net>
Date: Aug 26, 2019, 19:56 UTC
Message-ID: <20190826195634.GA27762@sigill.intra.peff.net>
In-Reply-To: <xmqqlfvlne3k.fsf@gitster-ct.c.googlers.com>

On Thu, Aug 22, 2019 at 01:23:59PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> 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