Ahhh, now I get it. Look at your repo directly after unzipping. You are sitting on master branch and the path mydir/org/my/package/My.java is not contained in HEAD anymore and also not in index. You successfully deleted that file during
the last commit. BUT: in your working tree that file is still existing. Since it is ignored we are not showing that file as "untracked" in staging view but in the filesystem it's still there.
To see the bug in JGit you don't have to do a complicated rebase now. Just try to checkout branch "my_branch". Already this fails in E/JGit. You want to overwrite the file containing "something interesting" with new content "something even
more interesting". And since the old content is not saved somewhere in index or HEAD JGit thinks you would loose unsaved data if we do this overwrite. The bug in JGit is that he doesn't correctly recognize that the file is ignored and can savely be overwritten.
It's complicated because during that checkout you are moving from a branch where a path X is ignored to a branch where path X is not ignored. JGit thinks that the file is not ignored (maybe JGit looks at the branch you are switching to, don't know yet). But
native git thinks the file should be ignored (possible looking at the branch we are coming from) and therefore doesn't care when it is up to overwriting file content.
Can you open a bug against JGit and attach that repo?