I'm currently looking at supporting both an .orgzlyinclude and an .orgzlyexclude file, with the same syntax but opposite effects. The include file would take priority. This would solve #217 as well.

My experiments are going well, I just need to figure out the right way to structure the code to avoid messiness and brittleness.

How about using the common syntax of .gitignore which allow to invert the ignore with !
When cloning a repo the ! in .orgzlyignore already works but does not work for updates yet.

You can probably parse the .orgzlyignore twice to once for ignore and once for includes to get to same semantice?!

Examples in #151 (comment) and #226

@stfl wrote:

How about using the common syntax of .gitignore which allow to invert the ignore with ! When cloning a repo the ! in .orgzlyignore already works but does not work for updates yet.

I'm glad you asked. I know that you can add exclusions in .gitignore and then make specific inclusions, but as I understand it, it's not really practical when you have nested directories, since you need to add "unexclude" rules on every level. I haven't used this myself, but I'm going by https://stackoverflow.com/a/5534865, and I concluded that this looks pretty tedious.

But if I'm wrong about that, it would of course be easier to stick with the current .orgzlyignore implementation. There should be no need to parse it multiple times.

(It's very possible that there are bugs in today's implementation - I haven't looked into it yet. But that's a separate issue.)

@amberin I like the simplicity of sticking with gitignore syntax, it is well-documented, there is an implementation, and people are most likely already familiar with it.

I'm not sure about the use cases. We're anyway looking only at org-files and non-org files are implicitly ignored, correct? So we are probably only looking at ignoring specific directories or file patterns?

An alternative could be something like python's MANIFEST.in (see the table with "Command" and "Description").

In which case I'd stick to exactly how they work and implicitly ignore any files that do not have an .org-suffix.

Ignore top-level attic folder:

global-include *.org
prune attic

Ignore all legacy files anywhere:

global-include *.org
global-exclude legacy-*

Only yop-level org-files and all anywhere in mobile folder:

include *.org
recursive-include mobile *.org

@chaoflow Interesting. I have no experience with the MANIFEST.in format, but it certainly sounds like a possibility.

I am now convinced that we should stick to a single .orgzlyignore file for now, implement it for all repo types, and then take another look at it if we get indications that many users are dissatisfied with the "mass exclude" possibilities that it offers. As @chaoflow said, only .org files are ever considered, and I now realize that it seems unlikely that people would have loads of different directory trees containing org files which they generally want to ignore, while loading multiple specific files many levels down.

I'm currently looking at supporting both an .orgzlyinclude and an .orgzlyexclude file, with the same syntax but opposite effects.

I realize this was not very clear. The idea was that both files would use the .gitignore format, but with opposite meanings. So no custom parser or syntax. But I've now dropped the idea.