Comment 1 for bug 1624725

This is a challenge.

In many ways duplicity is doing exactly what it is being asked to do. If a user wants a folder and everything in it, they could "--include folder/**". That said, in the example given, I completely see that a user doing "--include folder/" would expect duplicity to back up the folder and its contents, so that should ideally be the behaviour.

The slash matching folders only is useful, too, as somebody doing:
--include fo*/
would expect it to match "folder/" but not "foo.txt", so I'm not keen to reverse this change back out to how things were before (completely ignoring trailing slashes).

I therefore think that the correct solution to this would be for a matched include folder to include all of that folder's contents unless trumped by a higher-priority exclude. This is in essence how excludes already work for most cases, as the file traverser does not descend into excluded folders. It also seems consistent with Ken's comments in this email:
http://lists.nongnu.org/archive/html/duplicity-talk/2015-03/msg00020.html

The necessary consequence of that may be some of the more niche things, e.g.:
--include /var/log/**/
--exclude /var/log/**
including only the directory skeleton but no files would cease to work. On balance I think that is the lesser of two evils and I did mention in Bug #1479545 that I was not making the change to solve the directory skeleton use case. We can try to address these use cases from 0.8 onwards with specific flags (such as that suggested by Claus) or an equivalent of the "ignorecase:" prefix (so that it works in include-filelists).

I would appreciate any thoughts.