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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux