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

From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Lars Schneider" <larsxschneider@gmail.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>
Subject: Re: RFC: Proposing git-filter-repo for inclusion in git.git
Date: Thu, 22 Aug 2019 14:12:42 -0700	[thread overview]
Message-ID: <CABPp-BFK65qL4GCs5bFuiPPYwMCDYrxMyYejacVS89d2GK4nDQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqlfvlne3k.fsf@gitster-ct.c.googlers.com>

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.

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]

filter-branch is not merely a slow or difficult-to-use tool, it's one
that *fosters* mistakes by making it hard to get things right in
several different ways.  Granted, people exercise extra caution using
filter-branch because they know they need to, but there are so many
gotchas that they're likely to accidentally mess something up.  Those
mess-ups are not always discovered immediately, and by then it's
nearly cast into stone (rewriting being something you want to do very
rarely).

For as long as git-filter-branch is part of git.git and other tools
are outside, people will take that as a strong endorsement from us for
filter-branch and use it regardless of how much other education
exists...and that causes problems.

Thoughts?

Elijah

[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.