Re: git filter-branch not removing commits when it should in 2.7.0

[Junio C Hamano <gitster@pobox.com>]

John Fultz <jfultz@wolfram.com> writes:

> This seems to be a 2.7.0 regression in filter-branch.  The bug is reproducible on Mac/Windows (haven't tried Linux) in the 2.7.0 production releases.
>
> Make an empty repo and put an empty commit in the history.  E.g.,
>
> echo > foo && git add . && git commit -m "commit 1" && git commit --allow-empty -m "commit 2"
>
> Now try to use filter-branch to remove the empty commit.  Both of the following methods leave master unchanged, but both worked in 2.6.4:
>
> git filter-branch --prune-empty
> git filter-branch --commit-filter 'git_commit_non_empty_tree "$@"'
>
> Let me know if you need any more information.  Thanks.
>
> Sincerely,
>
> John Fultz
> jfultz@wolfram.com
> User Interface Group
> Wolfram Research, Inc.

Thanks.

Since there were only 5 changes to git-filter-branch.sh between
v2.6.0 and v2.7.0, it was fairly easy to pinpoint.

Reverting the following commit from v2.7.0 seems to give the same
result as v2.6.0 for "--prune-empty" experiment.

commit 348d4f2fc5d3c4f7ba47079b96676b4e2dd831fc
Author: Jeff King <peff@peff.net>
Date:   Fri Nov 6 01:24:29 2015 -0500

    filter-branch: skip index read/write when possible
    
    If the user specifies an index filter but not a tree filter,
    filter-branch cleverly avoids checking out the tree
    entirely. But we don't do the next level of optimization: if
    you have no index or tree filter, we do not need to read the
    index at all.
    
    This can greatly speed up cases where we are only changing
    the commit objects (e.g., cementing a graft into place).
    Here are numbers from the newly-added perf test:
    
      Test                  HEAD^              HEAD
      ---------------------------------------------------------------
      7000.2: noop filter   13.81(4.95+0.83)   5.43(0.42+0.43) -60.7%
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>