git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 19, 2016, 21:14 UTC
Message-ID
<xmqqbn8h9squ.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<AF975DD2-988F-47A8-BFC3-3BBC27419305@wolfram.com>
John Fultz <jfultz@wolfram.com> writes:
Show 19 quoted lines
> 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>
Previous: John FultzNext: Junio C Hamano
Message 2 of 19 in “git filter-branch not removing commits when it should in 2.7.0”
  1. John FultzJan 19, 2016
  2. Junio C HamanoJan 19, 2016
  3. Junio C HamanoJan 19, 2016
  4. Jeff KingJan 19, 2016
  5. Junio C HamanoJan 19, 2016
  6. filter-branch: resolve $commit^{tree} in no-index caseJeff King, Jan 19, 2016
  7. Jeff KingJan 19, 2016
  8. Jeff KingJan 19, 2016
  9. Junio C HamanoJan 19, 2016
  10. Jeff KingJan 19, 2016
  11. Jeff KingJan 19, 2016
  12. Jonathan NiederJan 20, 2016
  13. Jeff KingJan 20, 2016
  14. Junio C HamanoJan 20, 2016
  15. Jeff KingJan 20, 2016
  16. Junio C HamanoJan 20, 2016
  17. Junio C HamanoJan 20, 2016
  18. Jeff KingJan 20, 2016
  19. Jonathan NiederJan 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.