I want to note it down to invite anybody to assess the difference between an /e/ app fork and a similar version upstream. A major hurdle is the rebranding/package renaming.
As example I use the Mail fork of k9mail, but found out it’s not the best pick. It addresses this hurdle, not much else - the comparison breaks as soon as upstream does bigger refactorings. (With Mail it’s the migration to Kotlin in 5.700 that takes more steps to compare or better just fork again.)
I assume you have cloned both repositories… I use cli utils as I’m not fluent in any java tooling*
cd ~/git/e.foundation/apps/mail
grep -rlZ 'foundation.e.mail' . --exclude-dir=.git | xargs -0 sed -i 's/foundation\.e\.mail/com\.fsck\.k9/g'
for dir in $(find . | grep 'java/foundation/e/mail' | while read line; do echo ${line/\/mail*/\/mail}; done | uniq); do mkdir -p $dir/../../../com/fsck; mv -v $dir $dir/../../../com/fsck/k9; done
… and checked out tags/commit hashes that make sense to compare
meld ~/git/e.foundation/apps/mail ~/git/hub/k9mail
When you’re done, revert the changes in the fork
git restore .
git clean -fd
I’m happy to take suggestion for other useful oneliners, I’ll check what else I need with other examples from https://gitlab.e.foundation/e/apps
My feeling is that while forks give necessary control to quickly go ahead, it is hard to stay close to upstream long term if there’s no collaboration to accommondate /e/'s needs.
(* before I gave this feature in vscode-java a try and Rename Refactoring. A Java Dev should probably have better options with IntelliJ and others).