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

[Derrick Stolee <stolee@gmail.com>]

On 8/22/2019 5:12 PM, Elijah Newren wrote:
> On Thu, Aug 22, 2019 at 1:24 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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.

Yes please! Let's make the repo smaller.

> Ooh, if you're going to open this door, then a proposal I assumed
> would be shot down but which I'd be just about as happy with is:
> 
>   * Remove git-filter-branch from git.git.  Mention in the release
> notes where people can go to get it.[1]
> 
[snip]
>
> [1] We'd still have to decide where to put it.  If no one else wants
> to do it, I could include it in git-filter-repo with the promise that
> it's there for backward compatibility for those that still need the
> tool, even if I recommend folks use filter-repo instead.

May I recommend an idea, which may be silly?

We could strip these "extra" tools out of git.git and place them in
their own repos. The hope would be that they could build on their own
and have their own test suites.

Then, Git distributors could pick and choose the components they
bundle with Git. Dscho would know more about this sort of thing as
he distributes MinGit, which strips these things out already.

The biggest question is: how do we make sure that as git.git moves
forward that we don't break the ecosystem? Maybe we create a new,
larger repo that contains all of these subrepos? This would give
the community more experience dogfooding our own repo-splitting tools.

Personally, I like the idea of 'git subtree' over something like
'git submodule'. Using 'git subtree' may mean that tools like
'git-svn' that may be hard to split into a completely independent
repo could live primarily in the meta repo with a source dependence
on the included git.git subtree.

This "meta-git.git" repo could then be more flexible in adding
new tools like git-filter-repo or even git-lfs and friends. Again,
distributors could select a subset to include, but we would have
one place to run CI builds and make sure the tools are not
obviously breaking as git.git updates.

Thanks,
-Stolee