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

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

Elijah Newren <newren@gmail.com> 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.