Mentioned another implementation idea for this ticket in comments on #97. Basically, the "gimme the last successful backup" feature *could* be in a separate piped command that specializes in dealing with and parsing Borg JSON output. Example:
17 hours ago
Also, not necessarily a deal-breaker for the never-capture-Borg-output approach, but implementing #86 would *probably* require post-processing Borg JSON output in some way.. That is, unless it's implemented as a separate tool that's designed for post-processing direct Borg output, e.g.:
17 hours ago
If I recall correctly, the main reason for capturing Borg's JSON output and putting it in a JSON list is for the (fairly common) case of multiple repositories in a borgmatic configuration file or multiple separate borgmatic configuration files. The idea is that in a single borgmatic run, borgmatic may be invoking `borg --json` multiple times, and therefore need to gather the results into a common JSON list for ease of parsing by any downstream consumers of borgmatic output.
18 hours ago
Glad to hear that upgrading Borg cleared that up. For what it's worth, I've just set up a few more end-to-end tests in continuous integration to catch this sort of issue in the future. I've also mentioned a minimum Borg version in the README. Thanks for reporting the issue!
1 day ago
Got it. Thanks for the clarification. Borg version 1.0.11 is pretty old at this point. Have you tried upgrading? I can try to reproduce this later on, but it may be worth trying Borg 1.1.7 or thereabouts, if possible, to see if that fixes this. They may have changed their `--info` sub-command semantics.
2 days ago
I was indeed a little worried about the logging fixes changing the user experience for certain use cases. Looks like that's happened here!
4 days ago