Positional Arguments and Options: Order matters #213
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#213
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
Not sure if it is a feature request or bug relating to the order of how positional parameters are used.
Imagine file with patterns:
Then, there is a difference between the following commands.
In this case, borg backs up /home/john directory (and its contents) only once, even that technically the recursive root is stated twice (in patterns and as a positional parameter.)
in this case, borg backs up the directory twice (each file is added twice and deduplicated, obviously).
borg docs
Borg documentation suggest to use options before REPO::ARCHIVE
Borg only supports taking options (-s and --progress in the example) to the left or right of all positional arguments (repo::archive and path in the example), but not in between them:
Additional info
While
borg create
may be run without [PATH] parameter (as long as-R /path
is used inpatterns
file), it is not possible to deletesource_directories
in borgmatic's config.yaml (required parameter).What I would expect
There may be various solutions to this issue (like stating that in config.yaml notes for
patterns_from
directive), however, it may generally be better if borgmatic places options before REPO::ARCHIVE positional parameters to be consistent with borg recommendation and examples in documentation for each command.Environment
borgmatic version: 1.3.13-1
borgmatic installation method: AUR Arch package
Borg version: 1.1.10-1
Python version: 3.7.4
operating system and version: Arch Linux x86_64, up-to-date
That certainly makes sense to me. Seems like it'd be a pretty easy change to make across the board for all commands.
Thank you for pointing this issue out!
Does this seem like a desirable thing? Worth filing separately? Or not needed assuming this ticket is fixed?
I think the latter is a minor issue not worth considering for a separate ticket as long as the former one is fixed. Thanks!
Just fixed in master. And it'll be released as part of the next borgmatic release (hopefully soon). Thanks again!
And now released as part of borgmatic 1.3.15!