I think the best place is the repository. When someone downloads your repository he has everything what he needs to read all content correctly. The second thing is a backup, every copy of your repository is a whole backup of your project. And third, I want to maintain one repository instead three projects/resources.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
There’s one huge caveat to this: git is horrible at storing binary data. With text, it can store efficient diffs instead of whole files, but for binary files it has to store the whole file each time it changes. This, in turn, makes clone and pull times longer, makes the repo bigger (I’ve seen cases of repos with commits in the low thousands and only a few hundred kB of code that were nonetheless hundreds of MB in size simply because of trying to version frequently changing binary files), and also doesn’t really give you much in the way of useful info for versioning (yes, you can grab old versions, but you can’t inspect differences).
Yes, if it’s stuff like (uncompressed) SVG images then it does make some sense, but a lot of things people seem to like to put into README files are binaries, and they’re often big (especially screenshots these days).
If you really want to do this, git-lfs is really the only sane way to handle it.
The question is what do you want attach to README. I think, the most popular cases are screenshot images, a logo file, etc. In this case I think the repository is a rational place. But if you want to store many images, for example, for the documentation needs or .psd files ;) I think you need to put your files outside the repo.
I look at that problem like a the ratio of the work cost to impact to the future. If I knew that my files are not often changed, then I would put them to the repository. In the opposite situation (bad long term impact) I would put them outside.
Of course in this strategy the key is the good sense. And this you can only gain by a bigger experience.
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 think the best place is the repository. When someone downloads your repository he has everything what he needs to read all content correctly. The second thing is a backup, every copy of your repository is a whole backup of your project. And third, I want to maintain one repository instead three projects/resources.
There’s one huge caveat to this:
gitis horrible at storing binary data. With text, it can store efficient diffs instead of whole files, but for binary files it has to store the whole file each time it changes. This, in turn, makes clone and pull times longer, makes the repo bigger (I’ve seen cases of repos with commits in the low thousands and only a few hundred kB of code that were nonetheless hundreds of MB in size simply because of trying to version frequently changing binary files), and also doesn’t really give you much in the way of useful info for versioning (yes, you can grab old versions, but you can’t inspect differences).Yes, if it’s stuff like (uncompressed) SVG images then it does make some sense, but a lot of things people seem to like to put into README files are binaries, and they’re often big (especially screenshots these days).
If you really want to do this, git-lfs is really the only sane way to handle it.
The question is what do you want attach to README. I think, the most popular cases are screenshot images, a logo file, etc. In this case I think the repository is a rational place. But if you want to store many images, for example, for the documentation needs or .psd files ;) I think you need to put your files outside the repo.
I look at that problem like a the ratio of the work cost to impact to the future. If I knew that my files are not often changed, then I would put them to the repository. In the opposite situation (bad long term impact) I would put them outside.
Of course in this strategy the key is the good sense. And this you can only gain by a bigger experience.