Re: Bugs in git filter-branch (git replace related)

[Jeff King <peff@peff.net>]

On Thu, Jan 28, 2016 at 02:46:40PM +0000, Anatoly Borodin wrote:

> The `git replace` makes the second commit empty (use the file content from
> the first commit). It should disappear after `git filter-branch`, but it
> doesn't happen.
> 
> Bug 1: the empty commit stays.

I'm not sure if this is a bug or not. The "empty commit" check works by
checking the tree sha1s, without doing a full diff respecting replace
refs.

You're expecting git to notice a tree change, even though it never even
examined the tree in the first place (because you didn't give it a tree
or index filter).

Try:

  git filter-branch --prune-empty --tree-filter true master

which will force git to go through the motions of checking out the
replaced content and re-examining it.

This will run much more slowly, as it actually touches the filesystem.
In the general case, it would be interesting if filter-branch (or a
similar tool) could "cement" replacement objects into place as
efficiently as possible. But I'm not sure whether that should be the
default mode for filter-branch.

> Bug 2: the replace refs are not ignored (they can epresent blobs, trees etc,
> but even if they represent commits - should they be rewritten?).

You told it "--all", which is passed to rev-list, where it means "all
refs". I agree that running filter-branch on refs/replace is probably
not going to yield useful results, but I'm not sure if it is
filter-branch's responsibility to second-guess the rev-list options.

Probably the documentation for filter-branch should recommend
"--branches --tags" instead of "--all", though.

-Peff