Git is good because it allows us to keep our code synchronized. Git is bad because it requires a decent amount of infrastructure to work, and creating a git repo for a single file seems wrong because the amount of infrastructure might be greater than the file itself.
Sometimes we just want a file to be synchronized to multiple places, that we we don't have to copy code, in this context we can make a tradeoff, these clones of the file are only view only mirrors to the real thing, additionally they require manual updating. This means that if we want to modify the real file we have to go to the place where it exists to change it.
You might be lookin at this and thinking why do I need this when I can just use wget or curl to get the file. The reason is that whenever you have to do that you have to remember the link to the file, additionally whenever you want to update the file and get a newer version you again have to go and recall the url, by using indirect files, you store a file as its link and the system will automatically get that file and update it for you.
If you're ok with all the above, then indirect files might be good for you. The specific usage of it is that if you want the file flinks.py, you create the file flinks.py.ifile and then you put the contents as follows:
URL=https://toolbox.cuppajoeman.com/general_purpose_tools/filesystem/flinks.py
the link can be any link to a file not just on github
Then you run the indirect_files.py script on the directory in which that file exists (or any of its parent directories becuase it's recursive), and it will create the file that you're pointing to. The script looks like this:
other reasons you might use it
If someone has a huge repo, and you only want one file out of it, then you can use ifiles for this purpose, because sometimes repos come with a bunch of extraneous data or files you don't actually want.
fit
If you like this idea but are interested in how this could integrate with git so that the files are no longer read-only then check this out.