Degenerate pruning may remove non-empty merge commits

[vgriph]

When rewriting history, only keeping some paths, and a branch changing items on that file, where the change is reverted in the merge commit, still have the change applied.

To reproduce: Create a git repository as this:

git init
touch a.txt
git add a.txt
git commit -m '1'
touch b.txt
git add b.txt
git commit -m '2'
git checkout -b 'branch'
git rm a.txt
git commit -m '3'
git checkout master
touch c.txt
git add c.txt
git commit -m '4'
git merge --no-commit branch
git checkout HEAD a.txt
git commit --no-edit

Then perform a filter-repo

git filter-repo --path a.txt --force

This causes the rewritten tip to be empty.

Doing

git filter-repo --path a.txt --prune-degenerate never --force

on the other hand, leaves a.txt in the tip as expected.

$ git filter-repo --version
10401e45d5f0
$ git --version
git version 2.29.2.windows.2

[DougLeonard]

It leaves the correct commits (originally 1 and 3). Master just doesn't get placed on the 1st parent (1), which does seem odd.