A single large file is also sadness for incorporating suggestions from collaborators as you're always dealing with merge conflicts. Better might be a folder of plain text files, where each can have multiple lines in it, and they're grouped by theme or contributor or something.

A folder of plain text files will be sadness for performance. It's a file with basically line-wise entries, merge conflicts in that will be dead easy to resolve with Git locally. It won't be single-click in GitHub, but not too much of a hassle.

In fairness, I doubt most of these kinds of meme projects have a maintainer active enough to be willing to conduct local merges, even if it's "dead easy" to do so.

Maybe then this is really a request for Github to get better/smarter merge tools in the Web UI, particularly syntax-aware ones for structured files like JSON and YAML, where it would be much easier to guess, or even just preset AB and BA as the two concrete options available when both changes inserted new content at the same point. It could even read your .gitattributes file for supported mergers that would be able to telegraph "I don't care about the order" or "Order new list entries alphabetically" or whatever.

cf. https://github.com/jonatanpedersen/git-json-merge

It's ~fine for performance if you load them once at service startup. But I agree, merging is also no big deal.

Was wondering the same thing.. Probably cruft so it looks impressive at a glance.

If you ask LLMs for a long enough list of things, they often repeat entries.

There are 25 unique responses in that 1000-line file.

Once you remove the duplicates that are different only because of the typos in them, yes, that's correct.

It might be a weighted random.

Might be!

Not the way I'd approach it, but as a joke service, if it works it works.