I cloned an svn repository using git-svn. But I exluded everything except one folder (let's say folder A) using --include-paths. Since the svn repository contains many commits for other files (outside of that folder), in the resulting git repository I now also have many commits that reflect the same state as their parent commit and are in that sense "empty". How can I remove these commits from my git repository before pushing it for the first time?
I found the --prune-empty option in git-filter-repo, but I seems to only get active on those commits that are affected by other command options. At least
git filter-repo --prune-empty auto
or
git filter-repo --path 'A' --prune-empty auto
didn't change anything for me.
I found examples using filter-branch (https://stackoverflow.com/a/5324916/15137778), but I would like to avoid that as it is super slow (and also recommends filter-repo in it's docs). Is there a way to do it with filter-repo?
Here is an example in case the explanation was not clear:
Let's assume I have the following svn repository.
root
|-- A
|-- 1.txt
|-- 2.txt
|-- B
|-- 3.txt
|-- 4.txt
|-- C
|-- 5.txt
|-- 6.txt
Then I made a clone using git-svn only including the directory A which leads to this file structure in my new git repository:
root
|-- A
|-- 1.txt
|-- 2.txt
But the git repository still contains commits that changed for example C/5.txt in the original repository. So apparently all commits from the original svn repository were kept. But since that file was filtered out of my git repository, these commits refer to the exact same tree as their parent (no changes). So they are useless and I don't want to keep them. Thanks in advance for any help or advice.
There is a alternative "always" that will do it:
git filter-repo --prune-empty always --prune-degenerate always
--prune-empty {always, auto, never}
Whether to prune empty commits. auto (the default) means only prune commits which become empty (not commits which were empty in the original repo, unless their parent was pruned). When the parent of a commit is pruned, the first non-pruned ancestor becomes the new parent.
--prune-degenerate {always, auto, never}
Since merge commits are needed for history topology, they are typically exempt from pruning. However, they can become degenerate with the pruning of other commits (having fewer than two parents, having one commit serve as both parents, or having one parent as the ancestor of the other.) If such merge commits have no file changes, they can be pruned. The default (auto) is to only prune empty merge commits which become degenerate (not which started as such).