Closing in favor of #1184.
The only thing I'd recommend tweaking is how you display the default paths on the command-line.
Added a commit that does this.
Ready for merge from my side.
If you ask me, this approach here indeed looks better. It simplifies the code, both in terms of complexity and in terms of lines of code. The cost is that the code is a bit less DRY. But I think…
Indeed, it's a "fun" one... Now that I think about this again, one interpretation of that edge case is that having
expand_homefor the docs might be a bit over-engineered. As an alternative…
If I understand correctly, this is handled by parse_configuration() in borgmatic/commands/arguments.py instead. And that function restricts it to values read and config files, handles…
That's quite an annoying edge case you've discovered!
Indeed, it's a "fun" one... Now that I think about this again, one interpretation of that edge case is that having expand_home for the…
I see. Let me try to fix the tests.
borgmatic prune --files runs borg prune --list
Awesome, thanks! Let's hope it won't break too many old configs. ;)
borgmatic prune --files runs borg prune --list
On point 2, the intent with
--filesis that (forcreate), it does more than just--list, it also passes a--filterargument to Borg so that it doesn't show all file types by…
borgmatic prune --files runs borg prune --list
Just noticed that borg create has also --list but apparently we cover this via verbosity. Related: borgmatic-collective/borgmatic#195