This revision was meant to create a new branch, based on a copy of trunk. Instead it is based on a copy of the svn root (i.e. it copies trunk, branches and tags).
47332 reverts this. 47333 creates the correct branch.
It is actually convenient to be able to leave out the bad branch. But while the issue is solved for me, it may cause troubles for others.
Some additional notes: Running subgit verify on the result does not create any complaints. I do not know if that is correct. Obviously the git data is missing 2 commits. But I am not sure what verify is intended to check. So just mentioning it here.
It is actually known issue, such branches indeed take much time to translate because they contain the whole repository copy instead of trunk copy. Usually, it doesn’t lead to a fault yet translation of such a revision may take much time and this is what happened in your case, I suppose, as may look like a hang while SubGit is actually translating the revision.
The ‘verify’ subcommand indeed doesn’t warn about such branches/revisions as the main purpose of the command is to detect mirror corruptions, such as missed revisions in Git.
Usually, such branches are being detected and excluded on the configuration stage if ‘subgit configure’ is invoked with ‘layout auto’ option; or such an erroneous branch can be excluded manually using ‘excludeBranches’ configuration setting.