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

From: Jeff King <peff@peff.net>
Date: Jan 29, 2016, 06:18 UTC
Message-ID: <20160129061820.GB23106@sigill.intra.peff.net>
In-Reply-To: <loom.20160128T153147-396@post.gmane.org>

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

Show 5 quoted lines

> 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