mirror of
https://github.com/newren/git-filter-repo.git
synced 2024-07-18 00:01:41 +02:00
5ba62ba4e8
Pruning of commits which become empty can result in a variety of topology changes: a merge may have lost all its ancestors corresponding to one of (or more) of its parents, a merge may end up merging a commit with itself, or a merge may end up merging a commit with its own ancestor. Merging a commit with itself makes no sense, so we'd rather prune down to one parent and hopefully prune the merge commit, but we do need to worry about whether the are changes in the commit and whether the original merge commit also merged something with itself. We have similar cases for dealing with a merge of some commit with its own ancestor: if the original topology did the same, or the merge commit has additional file changes, then we cannot remove the commit. But, otherwise, the commit can be pruned. Add testcases covering the variety of changes that can occur to make sure we get them right. Signed-off-by: Elijah Newren <newren@gmail.com> |
||
|---|---|---|
| .. | ||
| basic | ||
| basic-filename | ||
| basic-mailmap | ||
| basic-numbers | ||
| basic-replace | ||
| basic-ten | ||
| basic-twenty | ||
| degenerate | ||
| degenerate-globme | ||
| degenerate-keepme | ||
| degenerate-moduleA | ||
| empty | ||
| empty-keepme | ||
| sample-mailmap | ||
| sample-replace | ||