I'd like to work on features of an app available in a public GitHub repo.
This repo contains the installation files and a directory (call it local
) in which are the local files that are indeed installed.
The app is already installed on my computer, so I'd like to fork only the local
directory to be able to work on it and test it directly, but don't know how I could version control it as the repo actually also contains the app install files ...
I tested git filter-branch
and its replacement git filter-repo
, but when I push it, install files are overridden.
Do I have to make a new repo I'll have to use as a submodule of the main repo ? I'm a bit lost
CodePudding user response:
Git fundamentally does not work with files or directories. It works with commits. The commits then contain files: not directories, just files; the file names have forward slashes in them, which triggers Git into making directories in your working tree, but the commits have files with long names with slashes in them.
The two commands you've mentioned, git filter-branch
and git filter-repo
, work by copying some or all existing commits to new and (supposedly) improved commits. These copies are no longer related to the original commits, so you can't combine the results back with the original repositories.
There exists a rather neglected Git command, git subtree
, that's aimed at the problem I think you're describing. However, its rather-neglected state—it's part of the Git source distribution but hidden away in contrib/subtree
where it languishes—makes me shy away from suggesting it, whether or not it might work.
Your best bet, given how Git works, is to go ahead and fork the entire repository. Then just build it as an alternative version; you might even install it as app-local
or app-test-version
or whatever. This way you can test what you're building, while still using the original app. If necessary, you can change it to work with different data-file inputs, so that the test version does not corrupt your original data, or just run it in a virtual machine so that it is all firewalled off from the "real" version of the app and the "real" data.
For information on setting up a virtual machine, look into VirtualBox or whatever other VM software is available for your system. (I've used VirtualBox a lot on macOS, and docker on Linux. Docker is not a true virtual machine: it's lighter weight, more like FreeBSD jails. But this generally makes it a lot harder to set up and use.)