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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html