![]() Be warned, this solution is a hack and should be treated as such. ![]() TL DR 12-01-2017 If you can use github's LFS or some other 3rd party, by all means you should. The solution I'd like to propose is based on orphan branches and a slight abuse of the tag mechanism, henceforth referred to as *Orphan Tags Binary Storage (OTABS) You could "purge" the huge repository from time to time in the same way: Your "git clone"'s will be faster. Then, I deleted the old branch, kept only the new branch, deleted the ref-logs, and run "git prune": after that, my. The "git log" for that branch only showed one commit. I used git-write-tree and git-commit-tree to create a new commit, without commit ancestors, and started a new branch pointing to that commit. deleting and renaming many times).Īt the end, I had only ~6 GB of MP3 files and ~83 GB in the. Then, I started to classify them in the habitual way (pushing, pulling, merging. I used an external hard disk drive with the main Git repository, and I cloned it into each computer. I had a very similar problem several months ago: ~21 GB of MP3 files, unclassified (bad names, bad id3's, don't know if I like that MP3 file or not.), and replicated on three computers. If you modify your binary files too often, then I would try to minimize the impact of the huge repository cleaning the history: I would use submodules (as Pat Notz) or two distinct repositories. The program will not work without the files. The files will not change very often (as in years), but they are very relevant to a program. ![]() The files are images for a program which generates PDFs with those files in it. What are your experiences/thoughts regarding this?Īlso: Does anybody have experience with multiple Git repositories and managing them in one project? It surely introduces some other things I haven't thought about.
0 Comments
Leave a Reply. |