I must say I find this to be a very strange question.
What's your reason for adding complexity to your workflow compared to storing them right next to your content?
Mostly because git repositories weren't meant ro to store media files, 🤔
Moreover my repo size would eventually get large as I write more (think 5+ years) since I add gif demos etc. making it hard to clone/maintain the repo.
I disagree.
The problem with binary files in a DVCS is when they exist in the history but no longer in any tip of branch, because you pay their weight without them actually being useful. In other words, versioning binary files should be avoided if possible, but that mostly applies to big binary files. Another way to look at it is that if Git wasn't meant to store binary files, then maybe it wouldn't give you the means to actually handle them anyway: git-scm.com/book/en/v2/Customizing...
And there you're storing files that are very likely to never disappear and never be updated (well, that depends on your workflow of course), so the file you're committing to your repo will also always be checked out.
Thinking 5+ years, what will grow is the size of the working tree. If you were to zip it and share the zip file, you'd have the exact same "problem". Adding a VCS to it isn't really the problem here (of course it'll almost double the size on disk, as each file is stored in the history in the .git/, and in the working tree, but that's true of any VCS, and needs to be balanced against the benefits a VCS gives you).
Lastly, if you have that possibility, you can use Git LFS for bigger binaries (think videos or big GIFs); both GitHub and GitLab support it. AFAICT, the binary won't be in your .git/, only in your working tree.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I must say I find this to be a very strange question.
What's your reason for adding complexity to your workflow compared to storing them right next to your content?
Mostly because git repositories weren't meant ro to store media files, 🤔
Moreover my repo size would eventually get large as I write more (think 5+ years) since I add gif demos etc. making it hard to clone/maintain the repo.
I disagree.
The problem with binary files in a DVCS is when they exist in the history but no longer in any tip of branch, because you pay their weight without them actually being useful. In other words, versioning binary files should be avoided if possible, but that mostly applies to big binary files. Another way to look at it is that if Git wasn't meant to store binary files, then maybe it wouldn't give you the means to actually handle them anyway: git-scm.com/book/en/v2/Customizing...
And there you're storing files that are very likely to never disappear and never be updated (well, that depends on your workflow of course), so the file you're committing to your repo will also always be checked out.
Thinking 5+ years, what will grow is the size of the working tree. If you were to zip it and share the zip file, you'd have the exact same "problem". Adding a VCS to it isn't really the problem here (of course it'll almost double the size on disk, as each file is stored in the history in the
.git/, and in the working tree, but that's true of any VCS, and needs to be balanced against the benefits a VCS gives you).Lastly, if you have that possibility, you can use Git LFS for bigger binaries (think videos or big GIFs); both GitHub and GitLab support it. AFAICT, the binary won't be in your
.git/, only in your working tree.