I believe there's some confusion around what git-subcopy does. It doesn't actually preserve history or anything like it. It just clones a certain file into your repository as a new commit, while saving which revision the file is from.
A potentially good candidate for using git-subcopy would be on this file: https://github.com/nix-community/rnix-parser/blob/master/ben.... It's copy-pasted from the nixpkgs upstream repository. It can't be used as a submodule - it's just one file out of dozens, no way people want to clone all that. Even worse with subtree, that'll always clone the whole upstream repo, and pollute the history on top of that. But the way it is currently, there's also no hint where it comes from.
git-subcopy is basically just me imagining a solution where you can not only link files or directories between repos without bloating down code size or history, but also modify them and later check what modifications you've made and rebase them. If you don't have a use case for this tool, good for you!
A potentially good candidate for using git-subcopy would be on this file: https://github.com/nix-community/rnix-parser/blob/master/ben.... It's copy-pasted from the nixpkgs upstream repository. It can't be used as a submodule - it's just one file out of dozens, no way people want to clone all that. Even worse with subtree, that'll always clone the whole upstream repo, and pollute the history on top of that. But the way it is currently, there's also no hint where it comes from.
git-subcopy is basically just me imagining a solution where you can not only link files or directories between repos without bloating down code size or history, but also modify them and later check what modifications you've made and rebase them. If you don't have a use case for this tool, good for you!