Make the --override option chainable #361

New Issue

Closed

opened 2020-10-21 22:27:27 +00:00 by ClementNerma · 4 comments

ClementNerma commented 2020-10-21 22:27:27 +00:00

Copy Link

Hi,

First of all thanks for making this great tool! I've used it for a bit of time now and I really enjoy its simplicity and the powerfulness of the configuration file.

I've a little suggestion for the documentation: it took me a long, very long time a few hours ago to realize that the --override argument took a list of arguments to override, instead of having to specify multiple --override ones that don't merge with each other.

This means that doing this:

$ borgmatic create --override key.a=... --override key.b=...

Is invalid and will result in only the second override clause being considered, which can be hard to debug as the documentation does not indicate how to perform multiple overrides.

So I would suggest to merge the --override arguments where multiple ones are provided to the borgmatic commands, as that's what most CLI do and is what most end users will implicitly think to.

Otherwise, I suggest to at least make the syntax clear in the documentation: if multiple items must be overriden, the following must be used:

$ borgmatic create --override key.a=... key.b=...

Thanks in advance!

Hi, First of all thanks for making this great tool! I've used it for a bit of time now and I really enjoy its simplicity and the powerfulness of the configuration file. I've a little suggestion for the documentation: it took me a long, very long time a few hours ago to realize that the `--override` argument took a list of arguments to override, instead of having to specify multiple `--override` ones that don't merge with each other. This means that doing this: ```shell $ borgmatic create --override key.a=... --override key.b=... ``` Is invalid and will result in only the second override clause being considered, which can be hard to debug as the documentation does not indicate how to perform multiple overrides. So I would suggest to merge the `--override` arguments where multiple ones are provided to the `borgmatic` commands, as that's what most CLI do and is what most end users will implicitly think to. Otherwise, I suggest to at least make the syntax clear in the documentation: if multiple items must be overriden, the following must be used: ``` $ borgmatic create --override key.a=... key.b=... ``` Thanks in advance!

witten commented 2020-10-23 22:35:33 +00:00

Owner

Copy Link

Thank you so much for taking the time to report this. I totally agree.. The current behavior + documentation on this is super confusing. I'll see what I can do to improve matters.

Thank you so much for taking the time to report this. I totally agree.. The current behavior + documentation on this is super confusing. I'll see what I can do to improve matters.

👍 1

witten referenced this issue from a commit 2020-10-23 23:06:26 +00:00

Merge override values when specifying the "--override" flag multiple times (#361).

witten commented 2020-10-23 23:07:10 +00:00

Owner

Copy Link

Fixed in master! You can now specify --override multiple times and everything gets merged properly. I'll also update the docs when I get a chance.

Fixed in master! You can now specify `--override` multiple times and everything gets merged properly. I'll also update the docs when I get a chance.

ClementNerma commented 2020-10-23 23:12:09 +00:00

Author

Copy Link

Wow that was quick!
Thanks for your amazing work :D

Wow that was quick! Thanks for your amazing work :D

👍 1

witten commented 2020-11-19 18:01:23 +00:00

Owner

Copy Link

Just released in borgmatic 1.5.11! (Still need to document properly.)

Just released in borgmatic 1.5.11! (Still need to document properly.)

🎉 1

witten referenced this issue from a commit 2020-11-19 19:02:41 +00:00

Update document about new --override behavior (#361).

witten closed this issue 2020-11-19 19:15:53 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

command-hook-steps

2.1.2

2.1.1

2.1.0

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.9.14

1.9.13

1.9.12

1.9.11

1.9.10

1.9.9

1.9.8

1.9.7

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels

blocked

breaking

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

No Label

Milestone

No items

No Milestone

Assignees

Clear assignees

witten

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#361