Re: [PATCH v5 3/4] Recommend git-filter-repo instead of git-filter-branch
- From
Elijah Newren <newren@gmail.com>
- Date
- Sep 4, 2019, 20:30 UTC
- Message-ID
- <CABPp-BEEb1gZbChjbNQt_anUL65Le3Zf=seM9m3yEN1sEBf=BA@mail.gmail.com>
- In-Reply-To
- <xmqqo901rrcs.fsf@gitster-ct.c.googlers.com>
On Tue, Sep 3, 2019 at 2:40 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
>
> Elijah Newren <newren@gmail.com> writes:
>
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index 5c5afa2b98..f805965d87 100755
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -83,6 +83,19 @@ set_ident () {
> > finish_ident COMMITTER
> > }
> >
> > +if [ -z "$FILTER_BRANCH_SQUELCH_WARNING" -a \
> > + -z "$GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS" ]; then
>
> This is probably the only place where [] instead of "test" is used
> in our shell scripts.
>
> if test -z "$FILTER_BRANCH_SQUELCH_WARNING$GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS"
> then
> ...Yeah, git-filter-branch.sh has approximately twice as many uses of [] than "test", so it seemed in line with its coding style. I can switch it over.
Show 21 quoted lines
> > + cat <<EOF > > +WARNING: git-filter-branch has a glut of gotchas generating mangled history > > + rewrites. Please use an alternative filtering tool such as 'git > > + filter-repo' (https://github.com/newren/git-filter-repo/) instead. > > + See the filter-branch manual page for more details; to squelch > > + this warning, set FILTER_BRANCH_SQUELCH_WARNING=1. > > + > > +EOF > > + sleep 5 > > +fi > > This should say it is "sleeping while showing the message and can > safely be killed before starting to do any harm"; alternatively it > should lose the "sleep". The user would have fear against typing ^C > to get out of a bulk history rewrite command, and the message itself > is making the fear worse. If your goal is to discourage its use, > then it would be a good idea to make it clear when it is safe to > kill it before going and studying the alternative. Otherwise, the > sleep does not help that much---the main complaint is that filter > branch is too slow, so the user has plenty of time to read the > message anyway, right? ;-)
Makes sense; will fix.