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